Re: can't release mutex

[David Sugar]

No, any OTHER thread that would have blocked on that lock will continue
after the timeout...so if you are using a common lock, you want another
thread to hit it, and use the wait to enter, as it can then see if the
lock got stuck, while your processing thread does so without a timeout....


Wakan wrote:
> OK David,
> first of all thanks for your precious help...
> only a clarifying question (clarifying for me of course... :)):
> 
> when the library function execution exceeds the timeout value,
> the piece of code in:
> 
>               if(!semimutex.wait(timeout)) {
>       ----------> library must have crashed, etc...
>               }
> 
> runs automatically? That is: is there a sort of "goto" that let the
> execution continue within the
> if statement? I put this question because (besides my ignorance), if I
> have to put an external loop that checks for the
> timeout, like...
> 
>       if(isPending(pendingInput)) {
>       --->    while(1) {
>                       if(!semimutex.wait(timeout)) {
>                               library must have crashed, etc...
>                       }
>                       call library function ...
>                       semimutex.post();
>               }
>       }
> 
> it probably won't resolve my problem, because when external library get
> stucked, the program can't go on,
> and never will reach the beginning of the external loop, never will
> excute the piece of code of the timeout condition.
> If there is an automatic "goto" instead, then I think it will work fine.
> 
> And more, in this way I can implement a sort of "time sharing", because
> even if my server is multithread, actually only 1 thread can execute until
> the library function exits (it isn't a fix execution time), so it's a
> fake multithread and performance speed is heavily penalized indeed.
> To have this working, I have to increase the couter of the semaphore?
> Can you make other example of the semaphore usage please?
> or suggest some documentation to read about this?
> 
> Thanks again for your help.
> Carlo
> 
> 
> David Sugar ha scritto:
>> What you are thinking of is something like this:
>>
>>      Semaphore semimutex(1);
>>
>>      ...
>>      if(isPending(pendingInput)) {
>>              if(!semimutex.wait(timeout)) {
>>                      library must have crashed, etc...
>>              }
>>              call library function ...
>>              semimutex.post();
>>      }
>>
>> Hence wait is used like a enterMutex, post like a leaveMutex, and only
>> one instance can pass through because it has a count of 1.  Since wait
>> supports a timeout, you can use that for your failure detect.
>>
>> The Common C++ Semaphore is actually implemented as a combination of
>> mutex and a conditional.
>>
>> Wakan wrote:
>>   
>>> Thanks for your reply.
>>> Can you write an example with the semaphore in this context?
>>> Thanks,
>>> Carlo
>>>
>>> Wakan ha scritto:
>>>     
>>>> Thanks for your reply.
>>>> Can you write an example with the semaphore in this context?
>>>> Thanks,
>>>> Carlo
>>>>
>>>> David Sugar ha scritto:
>>>>       
>>>>> I think what he really wants to do is use the Common C++ Semaphore with
>>>>> a count of 1, since semaphore can block with a "timeout", and with a "1"
>>>>> count in effect acts as a mutex...
>>>>>
>>>>> The larger question though of what to do with the stuck thread, perhaps
>>>>> from a broken library, is important also.  He could cancel the thread in
>>>>> question if it timed out, and put cleanup code in the thread destructor
>>>>> when he invokes delete to join it, but if the library allocated
>>>>> resources he cannot determine for them to get cleanly deallocated.
>>>>>
>>>>> Conrad T. Pino wrote:
>>>>>   
>>>>>         
>>>>>> You're on the right track.  Please pardon my rusty recollection syntax.
>>>>>> Revise:
>>>>>>
>>>>>>  mutex.enterMutex();
>>>>>>
>>>>>> to a form that accepts a timeout.  This example won't compile:
>>>>>>
>>>>>>  const int timeout = 500;
>>>>>>
>>>>>>  while (1) {
>>>>>>          if ( isPending( pendingInput ) ) {
>>>>>>                  int result = mutex.enterMutex( timeout );
>>>>>>
>>>>>>                  if ( result == success ) {
>>>>>>                          ---> protected function call (a function that 
>>>>>> can't work 
>>>>>>                          in multithread env) <---       
>>>>>>                          mutex.leaveMutex();
>>>>>>                  } else {
>>>>>>                          // do something else with pending input
>>>>>>                  }
>>>>>>          }
>>>>>>  }
>>>>>>
>>>>>> While the above will implement your timeout idea it does nothing about
>>>>>> the fundamental problem.  When the library "breaks" can be discoverd
>>>>>> and the blocked mutex/thread combination can be cancelled/restared
>>>>>> HOWEVER PROPRIETARY LIBRARY STATE IS INCONSISTENT & LIKELY DANGEROUS.
>>>>>>
>>>>>> If the library is dynamically loaded under your control then unload it
>>>>>> and reload it to get it back into a consistent state.  If it's auto or
>>>>>> static linked then you may have an unsolveable problem.
>>>>>>
>>>>>> If a reliable system is your goal then one of these MUST be true:
>>>>>>
>>>>>>          proprietary library NEVER fails
>>>>>>  OR
>>>>>>          proprietary library can be forced back to a consistent
>>>>>>          state because it has a reload or reinitialize method
>>>>>>
>>>>>> Good luck.
>>>>>>
>>>>>>     
>>>>>>           
>>>>>>> -----Original Message-----
>>>>>>> From: address@hidden
>>>>>>> [mailto:address@hidden Behalf Of Wakan
>>>>>>> Sent: Saturday, January 27, 2007 07:18
>>>>>>> To: address@hidden
>>>>>>> Subject: can't release mutex
>>>>>>>
>>>>>>> Hi,
>>>>>>> I'm using commoncpp library in a project that includes a multithread 
>>>>>>> server that
>>>>>>> can accept many tcp connection and each connection generates a thread.
>>>>>>> In this server I'm using a thirdy party proprietary library (compiled), 
>>>>>>> that (as the producer says)
>>>>>>> can't work in multithread environment.
>>>>>>> As each connection thread needs to call functions of this thirdy party 
>>>>>>> library, I've used a mutex to protect the piece of
>>>>>>> code where this external library function is called.
>>>>>>> In this way I can use this library fine, because all calls are 
>>>>>>> serialized and the protected function is called by one thread each time.
>>>>>>> This is an example:
>>>>>>> ...
>>>>>>>     while(1) {
>>>>>>>         if(isPending(pendingInput)) {
>>>>>>>                 mutex.enterMutex();
>>>>>>>                 ---> protected function call (a function that can't 
>>>>>>> work 
>>>>>>> in multithread env) <---       
>>>>>>>                 mutex.leaveMutex();
>>>>>>>        }
>>>>>>>     }
>>>>>>> ...
>>>>>>> in 99% of cases it works fine. But it accidentally happens that a 
>>>>>>> thread 
>>>>>>> can't exit from the mutex
>>>>>>> maybe because the thirdy party function freezes itself.
>>>>>>> When this happens, the server can accept other connections, soit still 
>>>>>>> works, but each thread can't enter in the mutex proteced piece of code.
>>>>>>> I'm thinking about something, like a timeout, that exits the mutex 
>>>>>>> after 
>>>>>>> a time, if the thread is not exiting...
>>>>>>> Can someone help me to resolve this problem? Are there other solutions?
>>>>>>> Thanks in advance,
>>>>>>> Regards
>>>>>>> Carlo
>>>>>>>       
>>>>>>>             
>>>>>> _______________________________________________
>>>>>> Bug-commoncpp mailing list
>>>>>> address@hidden
>>>>>> http://lists.gnu.org/mailman/listinfo/bug-commoncpp
>>>>>>     
>>>>>>           
>>>>> __________ NOD32 2011 (20070127) Information __________
>>>>>
>>>>> This message was checked by NOD32 antivirus system.
>>>>> http://www.eset.com
>>>>>
>>>>>   
>>>>>         
>>>>
>>>> __________ NOD32 2014 (20070128) Information __________
>>>>
>>>> This message was checked by NOD32 antivirus system.
>>>> http://www.eset.com
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Bug-commoncpp mailing list
>>>> address@hidden
>>>> http://lists.gnu.org/mailman/listinfo/bug-commoncpp
>>>>
>>>>
>>>> __________ NOD32 2014 (20070128) Information __________
>>>>
>>>> This message was checked by NOD32 antivirus system.
>>>> http://www.eset.com
>>>>
>>>>   
>>>>       
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bug-commoncpp mailing list
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/bug-commoncpp
>>>     
>>
>>
>> __________ NOD32 2014 (20070128) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>   
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-commoncpp

dyfet.vcf
Description: Vcard