Seems that Boost's shared_mutex is non recursive.. Is there anyway around this? (without re implementing the whole stuff)
have a look at this thread and this excellent explanation why shared_mutex
is bad idea in general. so if you don't agree that recursive_mutex
is bad idea too, just use it without any shariness because it cannot give you any performance boost. you'll receive even a bit cleaner code w/o any major changes.
I tried to use shared_mutex in my project to lock highly contested map when many threads often read data and rarely modify it. received a bit worse performance results
I've been down this road personally before. The simple answer is no, there is no shared_recursive_mutex.
I don't really agree with what others will tell you about how recursive mutexes are generally a bad idea, it certainly can save some time and prevent some errors. However, if you don't want to implement your own shared_recursive_mutex, you'll have to stick with non-recursive mutexes. It's not so bad.
I partially disagree with Andy that shared_mutex is a bad idea because it depends on your design i.e. how do you use it in your program. I believe that if you do long frequent reads with shared mutex it can bring you more efficient performance than if you would have used simple mutex for short more frequent locks for reading with rare writings. So shared_mutex is a way to do something long simultaneously. And I don't think that a long lock is a bad design in this case.
Do you support me or I am wrong?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With