Hmm that's a tough one. I think there are some guaranteed atomic instructions on the x86 arch, so you might be able to implement your own synchronization primitives in the shared memory structure... but that basically means that you run the risk of priority inversion your user task might be holding a lock that the realtime task needs.
However, if you are on a uniprocessor system, you may not need synchronization. Because the realtime task is never interrupted, you can be sure that any operations it performs on shared memory are going to be atomic. You just can't make the same guarantee about operations in the user task. As a general rule I avoid overly complex locking schemes by making communication more or less one-way in the shared memory structure. I designate some fields in the struct to be only modifiable by userland, and some to be only modifiable by the real time task. That way, I know that I avoid race conditions where userland clobbers the kernel or vice versa. I make sure that modifications to the shared memory buffer are non-transactional in nature (meaning they are basic things like assigning a simple value to an int, etc., which is atomic, you will never get _half_ the int assigned or anything like that.. however you should be careful with long longs as this is an emulated data type and modifying it is never atomic). Basically, if you are careful, you don't need to worry too much about synchronization. In general it is always a bad idea to try and synchronize a low-priority task with a high-priority one.. as you run the risk of entering a priority inversion scenario... -Calin On Tue, 30 Apr 2002, liaoting wrote: > I am a programmer in real time linux,can you tell me how to Shared memory >synchronisation > -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
