I would like to synchronize shared memory access but wanted to get some opinion here as to what would a better choice between mutex, semaphore (unnamed), or rwlock? Usually there is only one writter and many readers for a shared memory.
Thanks
I’d avoid rwlock because it isn’t kernel based and therefore it can’t help with issues like priority inversion.
My choice would be to use a mutex because I know this is SMP safe. While your application may not be running in an SMP system today, it might next year or the year after and there is nothing worse that suddenly having to debug something that stops working.
On the downside Mutex’s aren’t great for 1 Write/Many Reader systems so you may have to come up with some clever ways to copy the data (double buffer) to another area so multiple readers can read without needing a Mutex.
Tim
thanks for your input, and yes we are moving to SMP system soon, so this is another great tip. But what would be your reason for not using semaphore other than the performance reason compare to mutex.
The speed factor is the primary reason I normally use a Mutex. The secondary reason is my applications tend to use Mutexes between threads rather than between processes.
There is no good reason that I am aware of not to use a Semaphore beyond speed considerations.
If your system has multiple processes (vs multiple threads) accessing the Shared Memory region then I’d say a Semaphore is the way you want to go.
Tim
I thought mutex in QNX is okay to use either between threads or processes?
Yes mutex are ok to use between processes, but according to the doc they are faster when use between threads, that’s one of their advangates over semaphore.
If you don’t need priority inheritance, e.g. because the processes sharing the memory have the same priority anyway, I’d go for the rwlock, good for many readers and few writers.
thanks all for your input. For me it sounds like mutex is the way to go since we are moving towards SMP and priority inheritance is must. I just have to optimize on the many reader side if required…
How many readers do you have? Blocking them all on a mutex just because one is reading could be a major slowdown on SMP.
@Tim: any reason why a rw lock shouldn’t be SMP safe?
No 100% certain reason. So rw lock may be SMP safe. It all depends on how it is implemented under the hood. In the ‘Symmetric Multiprocessing (SMP)’ section of the doc’s it explicitly states that the pthread_mutex_lock family of calls is SMP safe. It mentions nothing about the pthread_rwlock family of calls.
So if we knew that pthread_rwlock used pthread_mutex under the hood we’d know it was SMP safe. Without knowing that I can’t be 100% sure. But the fact that the doc’s say the kernel has no knowledge of the rwlocks makes me wonder if it’s SMP safe.
Tim
rwlocks are built on top of a mutex/condvar.
I didn’t find the doc where it says the kernel doesn’t know about them.
The docs for pthread_rwlock_rdlock() say at one point, one of the error conditions is: “EFAULT - A fault occurred when the kernel tried to access rwl.” … so obviously the kernel is involved.
I’d say rwlocks are SMP safe. Actually, QNX boasts Multicore-support big time, so I’d be very surprised if something basic like this wouldn’t be.
Thunderblade,
Check the doc’s on the pthread_rwlock_init() function. There is a Caveat at the end of the doc for that function that states the kernel has no knowledge of them and thus can not fix priority inversion issues related to rw locks.
This is why I wasn’t sure if rw lock was using a pthread_mutex or something of its own creation.
Certainly if you have a multi-core processor I would think it would be easy to write a small test program to see if the rw lock works in SMP mode.
Tim