"Anthony Williams" <anthony.ajw@gmail.com> wrote in message news:87d466n1qh.fsf@dell.justsoftwaresolutions.co.uk...
"Chris M. Thomasson" <cristom@charter.net> writes: [...]
I still need to test drive the try lock functions in Relacy to see if I missed anything. As for the `SCHED_OTHER' issue, well, I am not sure how to get around that without sacrificing the 100% starvation free and bounded-time guarantees. Humm...
I forgot to destroy a resource in the failure case of the constructor. Here is code without the leak:
Thanks. Did you try it in Relacy?
No yet. I am going to try and get that accomplished within next couple of days.
It looks OK at a quick glance, but I'm not sure I haven't missed anything.
;^) Humm... Perhaps I should change the name from `fair_mutex' to `fair_rwmutex'? lol. http://pastebin.com/f16881bed (*) BTW, what are you're thoughts wrt the name change to `fair_rwmutex'? IMVHO, it sort of implies that the synchronization primitive is `SCHED_OTHER'... (*) This code has fixed an issue that only showed up when one attempted to upgrade a recursively acquired read lock to a write lock. The previous version would simply deadlock: ______________________________________________________ rw.rdlock(); rw.rdlock(); if (rw.tryrdtowr()) { rw.wrunlock(); return; } rw.rdunlock(); rw.rdunlock(); ______________________________________________________ Would deadlock. While the following would not: ______________________________________________________ rw.rdlock(); if (rw.tryrdtowr()) { rw.wrunlock(); return; } rw.rdunlock(); ______________________________________________________ Now, both versions will work. The first one with recursive read access will never be able to upgrade, while the latter might be able to.