I need some help of creating shared ddr sdram memory

[Altera_Forum]

Hi, everyone:), 

 My system is like this : Using NEEK, I created 2 processors both running in the ddr sdram. Processor1's reset vector offset is 0x100 and exception vector offset is 0x120. Processor2 's reset vector is 0x1000000 and exception vector offset is 0x1000020. As you can see, I didn't use the first 0x100 memory address space because I want to use it as the shared memory.    Then in my software of processor2, I created a float pointer pointing to the address DDR_SDRAM_BASE defined in the system.h and write some value to it. Processor1 will read and print the value pointed by address DDR_SDRAM_BASE in its program.   I think by doing this, processor2's change of the sdram should be reflected by processor1. Howerer, processor1 always print out 0.000 no matter what processor2 writes.   I feel confused :confused:   Can anyone help?

[Altera_Forum]

--- Quote Start ---  You'll need to use Dekker's algorythm on uncached memory to do any form of inter-cpu synchronisation. Generating a 'spin lock' is easiest, and, in fact, all the other synchronisation schemes are based on them.  --- Quote End ---       Hi, dsl, thanks for your reply.   However, Deckker's algorithm is kind of 'busy waiting' or 'spin lock' as you said. What I need is some kind of blocking machinism. Just like then recv() in socket programming , it will block the process. In mailbox, we have pend(). And though it seems that the lock() in Mutex is a blocking rountine, as I said before , it can not be used to coordinate processes.:(

[Altera_Forum]

In order to block a process (or similar) you need a scheduler that will spin waiting for some process to be runnable and then switch the stack pointer (and caller saved registers) to that of a the new process and then return back (restoring the rest of the the registers on the way) to where the new process blocked. 

 This is all hard and complicated and requires enough memory for a stack for each process. With multiple cpus it is even more complicated, since you need to do IPIs (inter processor interrupts) at various times to force the other cpu to perform some actions (with MMus and TLBs this is very fraught!)  For simple embedded systems it is easier to write a scheduler that just calls each possible function in turn (or functions from some active list). Nothing can block - every function has to return back to the scheduler before anything else can happen.  This can even alleviate the need for most interrupts, if they are not completely time critical there is no point, for example, moving a receive ethernet frame from the rx ring to a software linked list - the function that processes the frame can directly inspect the receive ring.  In a real MP scheduler all the blocking functions will, in some way, be implemented with code that runs with spin lock held.

[Altera_Forum]

OK. I see.......THx :）