Re: [boost] Re: Boost.Threads draft library submission

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-03-16 18:44:59

>> >Detecting the proper error condition in Win32 should 
>> >be trivial.
>> 
>> You would think so and it might even be so. But the 
>ReleaseSemaphore 
>> documentation in MSDN doesn't mention what error codes are returned 
>so 
>> you might have to go by the error your system is returning which 
>doesn't 
>> sound too good.
>
>This is one of those cases where you have to "follow the bouncing 
>ball", even when the ball goes behind that wall making it awfully 
>hard to see ;).  There's a well defined error returned from 
>GetLastError() in this case.  The code that I'll u/l later this 
>weekend handles this case if you're curious.

Like I said I didn't do a lot of digging. I just wanted to alert you to a 
potential annoyance.

>> Most programmer errors are "serious errors that result in 
>exceptional 
>> conditions".
>
>That I don't agree with.  A very large number of errors do not rise 
>to the point of "exceptional condition".  The difficulty is that 
>often developers disagree on specific errors, which I think is the 
>case here.  So, let me defend my stance a little better.
>
>The errors in question if not detected will result in deadlocks or 
>race conditions, both of which can be VERY difficult to diagnose.  
>Asserts are not valid here (the error still exists in Release builds, 
>and there's no gaurantee that a Debug build will ever be done, or 
>even if they are, that a specific path is tested under Debug).  Error 
>return codes are often (usually) ignored by programmers.  Exceptions 
>exist in both Debug and Release, can not be ignored, and give a good 
>indication of what went wrong and where.

I see your point and it's a very good one. However because lock objects 
aren't shared across threads it seems like asserts would catch the 
majority of errors. OTOH catching the majority of errors doesn't sound 
too good when you're dealing with something as tricky as multi-threading. 
:-)

>> Well there's nothing really wrong with having a lock as member data 
>and 
>> re-using it with a recursive mutex.
>
>Yes, there most certainly is.  The fact that you didn't catch this is 
>*precisely* why I want to discourage in every possible way this 
>misuse of the type.  The documentation clearly states that this is a 
>misuse, and yet you think it's a reasonable thing to do.  Let me 
>explain.  Lock types are not thread safe.  They maintain state to 
>indicate whether or not they've locked the associated mutex.  This 
>state is not protected by synchronization objects in any way (and to 
>do so would be detrimental to use).  

Of course. 

  -- Jesse