Archived
This forum has been archived. Please start a new discussion on GitHub.
RWRecLock - Again
Hi,
There was another thread about this topic, but I would appreciate it if someone could confirm that this was a feature and not a bug.
This works:
IceUtil::RWRecMutex::WLock sync(*this);
IceUtil::RWRecMutex::WLock sync(*this);
cerr << "Success.\n";
This doesn't work:
IceUtil::RWRecMutex::WLock sync(*this);
IceUtil::RWRecMutex::RLock sync(*this);
cerr << "Success.\n";
Even though the read lock is "more permissive" than the write lock.
Thanks,
There was another thread about this topic, but I would appreciate it if someone could confirm that this was a feature and not a bug.
This works:
IceUtil::RWRecMutex::WLock sync(*this);
IceUtil::RWRecMutex::WLock sync(*this);
cerr << "Success.\n";
This doesn't work:
IceUtil::RWRecMutex::WLock sync(*this);
IceUtil::RWRecMutex::RLock sync(*this);
cerr << "Success.\n";
Even though the read lock is "more permissive" than the write lock.
Thanks,
0
Comments
-
0
-
Thanks
OK,
Thanks for confirmation on this behavior. I had a little trouble interpreting the response in the referenced thread.
It would be nice to have some sort of a read lock that DID work inside a write lock:
obtain write lock
if (test_function())
set some value.
release write lock
test_function()
{
obtain read lock
return some status info.
release read lock
}
Without this, it makes it kind of a pain to have test functions that can be used in the context of a test/set and outside that context. With the current scheme, you need to put a write lock in your test function, which is more restrictive than necessary.
Cheers,0 -
You can always write a wrapper class for RWRecMutex that implements this behavior. For the RWRecMutex in Ice, we want to stick to Posix semantics, and introduce as little overhead as possible.
As an aside, can you please update your signature with the project you are working on? Please see this thread for details.0