bug-commoncpp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: can't release mutex


From: David Sugar
Subject: Re: can't release mutex
Date: Sun, 28 Jan 2007 14:27:44 -0500
User-agent: Thunderbird 1.5.0.9 (X11/20061219)

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

Attachment: dyfet.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]