reader/writer lock
|
Mar 8, 2012 at 7:59am
reader/writer lockHi. - 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! |
|
|
Mar 8, 2012 at 1:20pm
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, |
|
|
Mar 8, 2012 at 2:57pm
Hello, if efficiency is not needed … why use RW-Lock … ;-) Anyway interesting question ; anybody have experiences with pthread and SFU/SUA ? |
|
|
Mar 8, 2012 at 3:15pm
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, |
|
|
Mar 8, 2012 at 3:42pm
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, |
|
|
Mar 8, 2012 at 3:48pm
Hello, thanks Timothy for the link and to keep off-topic i found that interesting too (if you want to implement your custom cross-platform mutexes) : http://locklessinc.com/articles/pthreads_on_windows/ |
|
|
Mar 8, 2012 at 10:59pm
Thanks to everyone for your suggestions. In fact, the problem is quite specific: 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! |
|
|
Mar 9, 2012 at 7:12am
Hello, 1. currently i don’t care about Windows API … i do my stuff with POSIX and i’ll see later ; you are not the only one worried ;-) 2. to avoid main/timer thread problem in my [tralala] object i chose to do all the job only in timer threads ; data to paint are collected and duplicated there then used by the paint thread ; i have isolated the paint method from others. |
|
|
Mar 9, 2012 at 6:52pm
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 ! |
You must be logged in to reply to this topic.