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

[Reed, R. W <rob...@in...>]

When I saw this last night, it struck me then as a quasi-recursive locking scheme, quasi- because it doesn't require reference counting the nesting and a suitable number of unlocks to match the locks.  I don't think it's good practice to provide a method which most likely would be used only in implementing bad designs.

However, could implementing Florian's request be satisfied by simply replacing the !is_writer assertion in upgrade_to_writer with something like "if (is_writer) return false" in spin_rw_lock?  I'm not well versed enough in the code yet to know whether this opens any holes, but it seems to me that as long as you avoid a second call to internal_upgrade, things should be fine.  The story initially looks a little more complicated for queuing_rw_lock, but might be susceptible to a similar ploy, adding an "if" at the head of queuing_rw_mutex::scoped_lock::upgrade_to_writer() to check if state == STATE_WRITER.

It would only be a slight relaxation of the current rules and make upgrade_to_writer a noop if the write lock is already acquired, but assert as normal if the caller is not even a reader, etc, etc.

_______________________________________________________________________

Robert Reed                                     Rob...@in...

Intel SSG/ Developer Products Division/ Performance, Analysis and

    Threading Lab/ Technical Consulting

Dept. JF1-15, 2111 NE 25th Ave                      phone 503-264-9624

Hillsboro, OR 97124            mobile 503-830-1530     fax 503-264-9227



You can fool all the people all the time if the advertising is right

and the budget is big enough.

--Joseph E. Levine

________________________________________________________________________

________________________________
From: tbb...@li... [mailto:tbb...@li...] On Behalf Of Voss, Michael J
Sent: Friday, March 21, 2008 8:45 AM
To: Kukanov, Alexey; INNL TBB; Huson, Chris; Kim, Wooyoung; Poulsen, Dave; Robison, Arch
Cc: tbb...@li...
Subject: Re: [Tbb-develop] 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