mutex for multiprocessors with multi memories

[Altera_Forum]

Hi  

also if i have flash and sdram and sram  connected to multiprocessors(shared memory) can i manage them with one single mutex or do i need to have mutliple mutexes for each  of the shared memories or resources????  means i want to have single mutex control for all the memories shared by the processors  regards prasad

[Altera_Forum]

You need one mutex per subsystem you wish to control access to. By "subsystem," I mean any set of peripherals which work together. It could be a single register, or a memory block, some UARTs, or whatever. 

   --- Quote Start ---  originally posted by prasad_forums@Oct 21 2005, 07:54 AM means i want to have single mutex control for all the memories shared by the processors  --- Quote End ---   There you go; one mutex. This means that only one CPU can access any of the memories at a single time.  Bear in mind that the Avalon Bus Module knows nothing of your mutexes. It's not going to put a CPU into wait states if that CPU decides to skip the mutex and use the memory directly.

[Altera_Forum]

--- Quote Start ---  originally posted by mike desimone@Oct 21 2005, 11:24 AM you need one mutex per subsystem you wish to control access to.  by "subsystem," i mean any set of peripherals which work together.  it could be a single register, or a memory block, some uarts, or whatever.    --- quote start ---  originally posted by prasad_forums@oct 21 2005, 07:54 am means i want to have single mutex control for all the memories shared by the processors[/b]  --- Quote End ---   There you go; one mutex. This means that only one CPU can access any of the memories at a single time.  Bear in mind that the Avalon Bus Module knows nothing of your mutexes. It&#39;s not going to put a CPU into wait states if that CPU decides to skip the mutex and use the memory directly. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=10514)</div> [/b]  --- Quote End ---     Hi Mike, so in that case i need to have multiple mutexes suppose i want to have sram and sdram being shared. in that case if i have 2 mutexes and i can use them  independently .i.e i can write into sram from cpu0 using one mutex  and also into sdram using cpu1 concurrently .they can go independently. correct me if i am wrong.then how to take care which mutex corresponds to which shared resource????is it hardware or software. i mean ask that how to throw mutex and lock the particular memory only?  regards prasad

[Altera_Forum]

Hi, 

 For handling this kind of mutual exclusion problems another approach would be to use a single mutex peripheral, and then use a software handling of the mutual exclusion that exports an abstraction of "shared resource" that is independent on the partitioning scheme you are using in your multiprocessor.  In other words, each shared resource should have a "Resource" (kind of a binary semaphore), and the system should automatically take care of handling the mutual exclusion in the best way, resolving it on the same processor if all the tasks using the resource are assigned to the same CPU, or implicitly using an hardware mechanism such as the Altera Mutex if the resources are used by tasks allocated to different processors.  If the resource you are sharing are data structures shared in memory, you should also take care of disabling the cache when accessing the resource. Again, the system should take care of that automatically for you.  If you want, take a look at http://www.evidence.eu.com/nios2 (http://www.evidence.eu.com/nios2), you can find some on-line documentation and demos about the topic...  bye  Paolo

[Altera_Forum]

--- Quote Start ---  originally posted by prasad_forums@Oct 22 2005, 03:02 AM suppose i want to have sram and sdram being shared. in that case if i have 2 mutexes and i can use them  independently .i.e i can write into sram from cpu0 using one mutex  and also into sdram using cpu1 concurrently .they can go independently. correct me if i am wrong.then how to take care which mutex corresponds to which shared resource????is it hardware or software. i mean ask that how to throw mutex and lock the particular memory only?  --- Quote End ---   I guess you haven&#39;t used mutexes before, in hardware or software. They&#39;re really simple to use, you just have to be careful. They work like this:[list][*]Software wanting to access the shared resource locks the mutex. If the mutex is already locked, it waits until the mutex is unlocked (by whoever locked it). How this "waiting" happens is entirely up to the software.[*]Software uses the shared resource. [*]Software unlocks the mutex. [/list]The critical step is the first one, since the mutex&#39;s initial state must be recorded and the mutex locked in one atomic, uninterruptible operation. The mutex peripheral should implement this atomic operation (though I&#39;m not sure exactly how, since I have yet to use one).  So, in a nutshell, software is doing most of the work. Also, this mutex protection must be used whenever accessing the shared resource. Another thing to remember is that some mutexes cannot be called recursively, that is, if you lock a mutex, and then later on try to lock it again, your processing will wait forever. Also, if it isn&#39;t obvious, never use a mutex in an interrupt routine.  One last thing to keep in mind with multiple mutexes in a system is deadlock. If any process needs to acquire two mutexes to do its thing, then it must acquire those mutexes in a specific order (your choice) which must be adhered to by everything that uses any of those mutexes. For example, if mutexes A and B were each protecting memory regions, and you wanted to copy from one to the other, you would need to lock them in a certain order, say A first. If you didn&#39;t always lock in the same order, then you could get a deadlock as follows: CPU 1&#39;s code is written to lock A first, then B, but CPU 2&#39;s code wants to lock B before A. They just so happen to be running their respective code at the same time, so CPU 1 locks A, and CPU 2 locks B. Then they get to trying to lock the other lock, but it&#39;s locked, so they both wait forever: a system hang.