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: [EMAIL PROTECTED]
>>>>> [mailto:[EMAIL PROTECTED] Behalf Of Wakan
>>>>> Sent: Saturday, January 27, 2007 07:18
>>>>> To: bug-commoncpp@gnu.org
>>>>> 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
>>>> Bug-commoncpp@gnu.org
>>>> 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
>> Bug-commoncpp@gnu.org
>> 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
> Bug-commoncpp@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-commoncpp
begin:vcard
fn:David Sugar
n:Sugar;David
org:GNU Telephony
email;internet:[EMAIL PROTECTED]
tel;work:+1 201 215 2609
url:http://www.gnutelephony.org
version:2.1
end:vcard
_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-commoncpp
