问题
Seems that Boost's shared_mutex is non recursive.. Is there anyway around this? (without re implementing the whole stuff)
回答1:
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
回答2:
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.
回答3:
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?
回答4:
boost::recursive mutex is exclusive. I think you will need to extend shared_mutex. You can keep current thread ID in a set and check if it exist in the set in function providing lock.
回答5:
You'll have to use shared_ptr in those cases. Put your mutex in a shared_ptr and it'll do ref-counting on your mutex, which will gave you simmilar results.
来源：https://stackoverflow.com/questions/3308981/boost-recursive-shared-mutex