Topic: reader/writer lock

reader/writer lock

andrea agostini andrea agostini 2 63	Mar 8, 2012 at 7:59am 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 #62222
$Adam $Adam 1 7 45	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, Ádám #224748
nicolas danet nicolas danet 113	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 ? http://en.wikipedia.org/wiki/Windows_Services_for_UNIX #224749
$Adam $Adam 1 7 45	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, Ádám #224750
Timothy Place Timothy Place 10 124 40	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, Tim #224751
nicolas danet nicolas danet 113	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/ #224752
andrea agostini andrea agostini 2 63	Mar 8, 2012 at 10:59pm 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 #224753
nicolas danet nicolas danet 113	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. #224754
andrea agostini andrea agostini 2 63	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 ! #224755

You must be logged in to reply to this topic.