mutex for multiprocessors with multi memories

--- 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't used mutexes before, in hardware or software. They'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'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'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'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't always lock in the same order, then you could get a deadlock as follows: CPU 1's code is written to lock A first, then B, but CPU 2'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's locked, so they both wait forever: a system hang.