Re: Speaking of Multiprocessing...

From	Don Y <blockedofcourse@foo.invalid>
Newsgroups	comp.arch.embedded
Subject	Re: Speaking of Multiprocessing...
Date	2017-03-23 17:49 -0700
Organization	A noiseless patient Spider
Message-ID	<ob1q9q$c5u$1@dont-email.me> (permalink)
References	<ob1ij7$jja$1@dont-email.me> <rtKdndLJ5_hkyknFnZ2dnUU7-UednZ2d@giganews.com> <ob1leb$v25$1@dont-email.me> <rtKdnczJ5_g2w0nFnZ2dnUU7-UednZ2d@giganews.com>

Show all headers | View raw

On 3/23/2017 4:47 PM, Tim Wescott wrote:
> On Thu, 23 Mar 2017 16:26:46 -0700, Don Y wrote:
>
>> On 3/23/2017 4:19 PM, Tim Wescott wrote:
>>> On Thu, 23 Mar 2017 18:38:13 -0400, rickman wrote:
>>>
>>>> I recall a discussion about the design of an instruction set
>>>> architecture where someone was saying an instruction was required to
>>>> test and set a bit or word as an atomic operation if it was desired to
>>>> support multiple processors.  Is this really true?  Is this a function
>>>> that can't be emulated with other operations including the disabling
>>>> of interrupts?
>>>
>>> AFAIK as long as you surround your "test and set" with an interrupt
>>> disable and an interrupt enable then you're OK.  At least, you're OK
>>> unless you have a processor that treats interrupts really strangely.
>>
>> Rethink that for the case of SMP...  (coincidentally, "Support Multiple
>> Processors"  :> )
>
> D'oh.  Atomic to the common memory, not to each individual processor, yes.

Yes.  If the processor supports a RMW memory cycle AND the memory
arbiter honors that contract, then any competing processors would
explicitly be held off from accessing the location in question
until the RMW cycle terminated.

> Although it wouldn't have to be an instruction per se: you could have it
> be an "instruction" to whatever hardware is controlling the common
> memory, to hold off the other processors while it does a read/modify/
> write cycle.

Yes.  The point is that you have to be able to view state in specific
memory locations as functionally possible to "examine and alter"
indivisibly.  You can also introduce specific hardware mutexes but
then you are limited (in practical terms) by their number.

[I designed a processor many years ago that used such a mechanism to
synchronize with its peers]

You can also have the memory arbiter notice the cycle and "remember"
it even while allowing it to be "interrupted" (poor choice of
words) in the hope that the interruption does not COMPETE for that
particular memory location.  *If* the arbiter notices that the
interruption actually *does* compete for that location, then it
can explicitly act to stall that competing request until the
original "remembered" request has a chance to finish (presumably
"in short order").

It boils down to memory topology and the amount of resources you want
to throw at supporting multiple concurrent accesses.  As RMW's *tend*
to be infrequent, you can just opt for the easy way out...

By far, the easiest solution is a RMW memory cycle as you can then
design an arbiter to honor *it* while, conceivably, allowing OTHER
accesses to proceed in parallel (you just have to ensure that
the RMW accessed location is treated atomically; all others are
free to be accessed at will, concurrent with that RMW!)

Thread

Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-23 18:38 -0400
  Re: Speaking of Multiprocessing... Tim Wescott <seemywebsite@myfooter.really> - 2017-03-23 18:19 -0500
    Re: Speaking of Multiprocessing... Don Y <blockedofcourse@foo.invalid> - 2017-03-23 16:26 -0700
      Re: Speaking of Multiprocessing... Tim Wescott <seemywebsite@myfooter.really> - 2017-03-23 18:47 -0500
        Re: Speaking of Multiprocessing... Don Y <blockedofcourse@foo.invalid> - 2017-03-23 17:49 -0700
          Re: Speaking of Multiprocessing... upsidedown@downunder.com - 2017-03-24 09:48 +0200
            Re: Speaking of Multiprocessing... Don Y <blockedofcourse@foo.invalid> - 2017-03-24 01:22 -0700
        Re: Speaking of Multiprocessing... Clifford Heath <no.spam@please.net> - 2017-03-24 21:04 +1100
          Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:01 -0500
            Re: Speaking of Multiprocessing... Clifford Heath <no.spam@please.net> - 2017-03-25 18:49 +1100
    Re: Speaking of Multiprocessing... Grant Edwards <invalid@invalid.invalid> - 2017-03-24 14:36 +0000
  Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-23 22:43 -0500
    Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 01:05 -0400
      Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 00:37 -0500
        Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 01:58 -0400
          Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 02:07 -0500
            Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 13:36 -0400
              Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 19:06 +0100
                Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 14:12 -0400
                Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-25 01:48 +0100
                Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 22:10 -0400
                Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-25 15:25 +0100
                Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-25 15:27 -0400
                Re: Speaking of Multiprocessing... upsidedown@downunder.com - 2017-03-25 22:43 +0200
                Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-25 17:06 -0400
                Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-26 17:28 +0200
                Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-26 13:27 -0400
              Re: Speaking of Multiprocessing... Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-25 00:42 +0200
                Re: Speaking of Multiprocessing... rickman <gnuarm@gmail.com> - 2017-03-24 19:22 -0400
                Re: Speaking of Multiprocessing... Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2017-03-24 16:33 -0700
                Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:47 -0500
                Re: Speaking of Multiprocessing... Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-25 12:40 +0200
                Re: Speaking of Multiprocessing... Robert Wessel <robertwessel2@yahoo.com> - 2017-03-26 00:42 -0500
  Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 09:17 +0100
    Re: Speaking of Multiprocessing... Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-24 09:28 +0000
      Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 11:19 +0100
        Re: Speaking of Multiprocessing... Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-24 11:06 +0000
          Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 12:21 +0100
        Re: Speaking of Multiprocessing... Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-24 16:09 +0000
          Re: Speaking of Multiprocessing... David Brown <david.brown@hesbynett.no> - 2017-03-24 17:33 +0100
            Re: Speaking of Multiprocessing... Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-24 17:52 +0000

csiph-web