reader/writer lock
Hi.
I need to implement a cross-platform reader/writer lock, and I am not really sure about what to do:
- on the Mac, I could use pthreads – which, if I understand correctly, forms the core of the various systhread functions. But then, what to do in Windows? Using pthreads for Windows? (would that be a good idea?) Or the native API, which I really don’t know?
- or I could implement a rw-lock based on the mutexes and condition variables of the Max API. It wouldn’t probably be the most efficient mechanism in the world, but the context would not be very critical, with no more than two threads competing for the lock.
What do you think is the best strategy?
Thank you!
aa
Hi Andrea,
if efficiency is not a crucial question, I would definitely go for the mutexes included in the Max API. They are reliable, cross-platform and easy to maintain.
Best,
Ádám
Hi,
as I understand, the problem of a shared resource doesn’t have to do anything with efficiency. You may have time-critical situations for using a shared resource (for instance, if you’re communicating with a device in, let’s say, signal rate time) just as well as situations where time doesn’t really matter (e.g. printing). In the first situation, I’d definitely solve my problem with atomic operations, as much as I can. In the latter, the Max API mutexes are just fine.
Actually, to implement a true RW-lock (multiple reading and single writing) I would probably use a mutex to control writing and a counter with the built-in atomic increment/decrement macros for reading.
HTH,
Ádám
I agree with most of what has been written here. If you are writing for Max then the systhread API is pretty thorough and full-featured and definitely recommended. If you are outside of Max then the topic is venturing toward being a little off-topic (not that that’s necessarily a bad thing).
If you want an example of some code for the simplest (i.e. not fully-featured) cross-platform mutex, this bit of code might be helpful:
https://github.com/jamoma/JamomaFoundation/blob/master/library/source/TTMutex.cpp
There used to be a TTLock class which was based on more of a RAII model but I can’t seem to find it quickly. It had the benefit that you couldn’t forget to release the lock because it locking/unlocking was based on the existence of the lock on the stack.
Cheers,
Tim
Thanks to everyone for your suggestions.
In fact, the problem is quite specific:
- a quite bulky operation triggered by a clock (scheduler thread), reading a data structure:
- a quite bulky operation in the paint method (main thread), reading a data structure; and
- potentially, some write operation in either thread.
So, basically, I don’t want the paint and clock operations to block each other, but I want the write operation to be thread safe. This is why I need a rw-lock. I am pretty sure that
Vanille, your link seems very very interesting. I am always a bit worried when dealing with the Windows API, I always have the feeling of entering some wild, messy place – but I know, this thing is called racism… But I might give it a try this time – this stuff looks quite reasonable to me ;)
… but for a start I’ll try to implement my own (probably not-so-good) rw mutex, based upon the systhread API. I already have some ideas… I’ll let you know what I come up with!
Thanks again – and still yearning for more advice!
aa
Yes, but you see, with bach we’re keeping everything cross-platform, so – alas – I must care about Win…
and the data structure for, say, a score is way too complex to duplicate everything for the paint method: so we need to lock the structure. we use a standard mutex, for now, but a rw mutex is clearly a much better choice.
Thank you anyway – I’ll check out your link asap !