Re: Speaking of Multiprocessing...

From	rickman <gnuarm@gmail.com>
Newsgroups	comp.arch.embedded
Subject	Re: Speaking of Multiprocessing...
Date	2017-03-25 17:06 -0400
Organization	A noiseless patient Spider
Message-ID	<ob6lvv$cfi$1@dont-email.me> (permalink)
References	(9 earlier) <ob4ek3$8v4$1@dont-email.me> <ob4jdu$k87$1@dont-email.me> <ob5uft$ueq$1@dont-email.me> <ob6g6b$pke$1@dont-email.me> <g9lddc9sd0gc9ivj62980lesmdu62k7hs3@4ax.com>

Show all headers | View raw

On 3/25/2017 4:43 PM, upsidedown@downunder.com wrote:
> On Sat, 25 Mar 2017 15:27:55 -0400, rickman <gnuarm@gmail.com> wrote:
>
>> On 3/25/2017 10:25 AM, David Brown wrote:
>>> On 25/03/17 03:10, rickman wrote:
>>>> On 3/24/2017 8:48 PM, David Brown wrote:
>>>>> On 24/03/17 19:12, rickman wrote:
>>>>>> On 3/24/2017 2:06 PM, David Brown wrote:
>>>>>>> On 24/03/17 18:36, rickman wrote:
>>>>>>>> On 3/24/2017 3:07 AM, Robert Wessel wrote:
>>>>>>>>> On Fri, 24 Mar 2017 01:58:26 -0400, rickman <gnuarm@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On 3/24/2017 1:37 AM, Robert Wessel wrote:
>>>>>>>>>>> On Fri, 24 Mar 2017 01:05:02 -0400, rickman <gnuarm@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 3/23/2017 11:43 PM, Robert Wessel wrote:
>>>>>>>>>>>>> On Thu, 23 Mar 2017 18:38:13 -0400, rickman <gnuarm@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>>
>>>>>>>>>> There certainly is no reason for memory to be multiple cycle.  I
>>>>>>>>>> think
>>>>>>>>>> you are picturing various implementations where memory is slow
>>>>>>>>>> compared
>>>>>>>>>> to the CPU.  That's not a given.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, but such a situation is sufficiently uncommon that you'd really
>>>>>>>>> want to spec it up front.  Most cores these days don't even have
>>>>>>>>> single cycle L1 caches.
>>>>>>>>
>>>>>>>> Again, assuming an architecture and requirements.  This
>>>>>>>> conversation is
>>>>>>>> not about designing the next generation of ARM CPU.
>>>>>>>
>>>>>>> It would be making architecture assumptions to require single-cycle
>>>>>>> memory - saying that memory may be multiple cycle is the general case.
>>>>>>>
>>>>>>> (You might /want/ to make architecture assumptions here - I gave some
>>>>>>> other suggestions of specific hardware for locking in another post.
>>>>>>> The
>>>>>>> solutions discussed here are for general memory.)
>>>>>>
>>>>>> We are having two different conversations here.   I am designing a CPU,
>>>>>> you are talking about the theory of CPU design.
>>>>>
>>>>> Aha!  That is some useful information to bring to the table.  You told
>>>>> us earlier about some things that you are /not/ doing, but not what you
>>>>> /are/ doing.  (Or if you did, I missed it.)
>>>>>
>>>>> In that case, I would recommend making some dedicated hardware for your
>>>>> synchronisation primitives.  A simple method is one I described earlier
>>>>> - have a set of memory locations where you the upper half of each 32-bit
>>>>> entry is for a "thread id".  You can only write to the entry if the
>>>>> current upper half is 0, or it matches the thread id you are writing to
>>>>> it.  It should be straightforward to implement in an FPGA.
>>>>>
>>>>> The disadvantage of this sort of solution is scaling - if your hardware
>>>>> supports 64 such semaphores, then that's all you've got.  A solution
>>>>> utilizing normal memory (such as TAS, CAS, LL/SC) lets user code make as
>>>>> many semaphores as it wants.  But you can always use the hardware ones
>>>>> to implement more software semaphores indirectly.
>>>>
>>>> I guess I didn't explain the full context.  But as I mentioned, it is
>>>> simpler I think to include the swap memory instruction that will allow a
>>>> test and set operation to be implemented atomically without disrupting
>>>> any other functions.  It will use up an opcode, but it would be a simple
>>>> one with the only difference from a normal memory write being the use of
>>>> the read path.
>>>>
>>>
>>> Well, you are the one implementing this - so you have to figure out what
>>> solution makes most sense for you.  Here's another idea you could consider.
>>>
>>> If you are dealing with just one CPU here, I have always thought a
>>> "disable interrupts for the next X instructions then restore interrupt
>>> status" instruction would be handy - with X being something like 4. That
>>> would let you do atomic reads, writes or read-modify-write instructions
>>> covering at least two memory addresses, without need for special memory
>>> or read-write-modify opcodes.
>>
>> How is that different from instructions to enable and disable
>> interrupts?  This doesn't really help me as there are N logical CPUs.
>> They just share the same hardware.  But they all run concurrently in
>> nearly every sense.  They just use different clock cycles so that memory
>> accesses are not literally concurrent.  So interrupts aren't the (only)
>> issue.
>
> I thought that SMP stands for _symmetric_ multiprocessing.
>
> Disabling interrupts works well when dealing with one CPU and
> peripherals or the case with one master supervisor CPU and a lot of
> slave CPUs (AMP).

I don't follow how disabling interrupts will help resolve multiple CPUs 
accessing the same memory location?  Disabling interrupts only stops 
other processes on the same CPU from accessing the same memory location. 
  How would that prevent processes on other CPUs from accessing that 
location during the multiple instruction access of the process in 
question?

-- 

Rick C

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