Re: [Tbb-develop] Making upgrade_to_writer not fail if already locked for writing?

[Robison, A. <arc...@in...>]

As far as I know, the only way in pthreads to query the state of a lock
is to use pthread_mutex_trylock.  TBB has the same capability.   I think
this is similarly true for Windows
<http://msdn2.microsoft.com/en-us/library/ms686360(VS.85).aspx> .
Likewise for C++ 200x
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html> .
Since none of these other libraries have any other way to query the
state of a lock, and all are designed by threading experts, I conclude
that adding another query function is a bad idea.

I concur with Wooyoung's suggestion.

- Arch

_____________________________________________
From: Kim, Wooyoung 
Sent: Monday, March 24, 2008 9:38 AM
To: Voss, Michael J; Kukanov, Alexey; INNL TBB; Huson, Chris; Poulsen,
Dave; Robison, Arch
Cc: 'tbb...@li...'
Subject: RE: Making upgrade_to_writer not fail if already locked for
writing?

If an application needs to know the state of a lock, it may declare a
separate variable and keep track of the state.
When the lock is acquired, it may raise a flag, and before it calls
'release()' it lowers the flag.
Better yet, it writes thread ID onto it, so that it knows which thread
has acquired the lock.
Given this option, is the overhead for supporting such a functionality
in the mutexes themselves justified?
By doing so, we would charge other applications that would not need such
a functionality.

best regards,

-------------------------
Wooyoung Kim
+1 217-621-9968
wooyoung dot kim at intel dot com

_____________________________________________
From: Voss, Michael J 
Sent: Friday, March 21, 2008 10:45 AM
To: Kukanov, Alexey; INNL TBB; Huson, Chris; Kim, Wooyoung; Poulsen,
Dave; Robison, Arch
Cc: 'tbb...@li...'
Subject: RE: Making upgrade_to_writer not fail if already locked for
writing?

Isn't this related to the general question of whether a recursive mutex
is a good thing? We had this discussion some time ago and then
eventually decided to supply a recursive_mutex class. It's seems that
the tradeoffs are the same here, pragmatism -vs- idealism.  We did,
however, decide to create a separate class instead of making all of our
mutex classes recursive. The thought was that we could appropriately
document that using the recursive variant might indicate a bad design.

So following our previous decisions, maybe we provide a method to query
the current state, and then document that using it probably indicates
that you have a bad design.

Mike

_____________________________________________
From: Kukanov, Alexey 
Sent: Friday, March 21, 2008 3:32 AM
To: INNL TBB; Huson, Chris; Kim, Wooyoung; Poulsen, Dave; Robison, Arch;
Voss, Michael J
Cc: tbb...@li...
Subject: Making upgrade_to_writer not fail if already locked for
writing?

There was a request at the forum to make upgrade_to_writer work (and not
run into an assertion) if the call is made when a lock is already held
for writing. Here is a quotation:

"If you try to call the method on a lock which is currently in the
active_writer state however, one will run into an assertion. If one
additional check would be introduced to the method  (ok, which would
mean some overhead) to see if the lock is already in the requested state
and simply return without doing anything,  my problem would be fixed
without changing the interface. 

Do you think there is any harm in such extension?

Another suggestion discussed in the thread was to provide a method that
returns the current state of the mutex. I personally find this being not
a good idea; in my opinion, a good design should not rely on methods
requesting mutex state. Is there a similar functionality for mutexes in
pthread or Win32 API?

Regards,
- Alexey