Re: can't release mutex

[Wakan]

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]On 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