- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have some questions for which I was not able to find an answer in the documentation.
1- What happens if a thread acquires a lock to a spin_mutex, then it invokes a method than tries to lock the same mutex again? Does the second lock do nothing? or does it meet a deadlock?
2- Now consider the spin_rw_mutex with a method that firstly acquires a reading lock to the mutex, then it invokes a method with a writing lock, without upgrading it. What happens? deadlock?
I think that basically I am looking for something that combines the recursive property with the r/w capabilities...
Thanks
- s.fox
I have some questions for which I was not able to find an answer in the documentation.
1- What happens if a thread acquires a lock to a spin_mutex, then it invokes a method than tries to lock the same mutex again? Does the second lock do nothing? or does it meet a deadlock?
2- Now consider the spin_rw_mutex with a method that firstly acquires a reading lock to the mutex, then it invokes a method with a writing lock, without upgrading it. What happens? deadlock?
I think that basically I am looking for something that combines the recursive property with the r/w capabilities...
Thanks
- s.fox
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. It will livelock, busy-waiting forever.
2. Same thing. You should definitely try to upgrade, instead.
A ReaderWriterMutex (referring to the concept) implies that you know when you already hold the mutex (for reading) when trying to acquire it again (for writing), so to me at least it seems a little strange to want to combine that with not knowing (recursiveness)...
2. Same thing. You should definitely try to upgrade, instead.
A ReaderWriterMutex (referring to the concept) implies that you know when you already hold the mutex (for reading) when trying to acquire it again (for writing), so to me at least it seems a little strange to want to combine that with not knowing (recursiveness)...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
s.fox,
(other than for bad programming) This sounds like an opportunity for you to add a thread local variable that is used to indicate if your thread currently owns the lock.
__declspec (thread) myFooLockCount = 0;
...
if(myFooLock++ == 0) doFooLockHere();
...
if(--myFooLock == 0) doFooUnlockHere();
Jim Dempsey
(other than for bad programming) This sounds like an opportunity for you to add a thread local variable that is used to indicate if your thread currently owns the lock.
__declspec (thread) myFooLockCount = 0;
...
if(myFooLock++ == 0) doFooLockHere();
...
if(--myFooLock == 0) doFooUnlockHere();
Jim Dempsey
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page