Hi, I have a small problem that I'd like to fix elegantly. I have written a mutex wrapper-class that allows multiple read-locks at the same time. It does this by locking an internal mutex the first time a read-lock is requested and unlocking it the moment the last read access is unlocked. However, the last unlock can be done by a different thread than the one doing the initial lock: My problem is that I end up with deadlocks, the thread that should unlock the mutex doesn't have the rights and fails to unlock it and the mutex is locked forever. I know ways around this but they involve Sleep's and I don't like too use too many of those. So my question is, can I have one thread release a mutex 'owned' by a different thread? ...hopefully I can :) thanks for your help

Well I don't know exactly how you've implemented it all, but it might be easier if the mutex is owned by another object from which you obtained a wrapped mutexes via a static method (eg a factory which maps names to a mutex wrapper what returns a reference to the mutex wrapper). The wrapped mutex adds or removes references to the mutex in the map (via specific methods)... the method will (as appropriate) create/lock a mutex, or unlock it. I don't know if I've expained this well, or if this is a standard approach, but it's one I've used before.
Hope you get it working,

Dan

What kind of threading api are you using? I know that if you're using pthread, it will result in undefined behavior.

Quote:Original post by Jeroen Stout
I have written a mutex wrapper-class that allows multiple read-locks at the same time. It does this by locking an internal mutex the first time a read-lock is requested and unlocking it the moment the last read access is unlocked.

Are you counting the number of read locks? .. if so, are you counting in a thread-safe manner? :(

You may not want to hear this, but if you want an elegant solution you might want to do some serious refactoring. What you are proposing sort of defeats the whole purpose of mutexes. :-)

I was going to say use a semaphore instead, but it seems that there's no way (that I can see atm) to know what the count on a semaphore is using the Win32 API, which means you can't know if a lock is still being held by some thread, otherwise you could create a semaphore initialized to the max number of read locks you wanted to allow.

Maybe try implementing your own read locks using atomic ops?