Re: pb : semaphore crashing with kernel 2..4.x

[David Sugar]

We recently changed the implimentation from using semaphores to using a 
construct built from a conditional, as it was far more portable and 
allowed for timeouts on wait.  I do recall hearing that some specific 
versions of glibc have broken implimentations of conditionals, however. 
 Is this a machine built with debian woody and the glibc version it uses?
Which version of Common C++ are you using?

Stephane Domas,,, wrote:
> hello
>
> I'm writing you to ask if you already seen problems with semaphore and 
> thread termination under kernel 2.4.X.
> To describe more precisely my problem :
>
> I launch a process, which instanciate 7 semaphores, agregate in a 
> Handler object. Then the process  launches 3 threads (let's call them S, 
> R, and C). These three threads own the Handler object, so they can post 
> and/or wait on these semaphore. 3 first semaphore are used by the 
> process to wake up S,R,C and the three others are used by S, R and C to 
> signal to the process that they are stopped.
>
> Further in the execution, the process launches a new thread (let's call 
> it T) that also owns the handler object. And for an obscur reason, when 
> this thread or another one do a post on the the 7th semaphore, it 
> crashes. Very surprisingly, this crash does not occur on a 2.6.X kernel.
>
> Another bug [ if I do not post on the 7th semaphore ] : if I let the 
> last thread T ends himself, it calls the final method which only 
> contains a message print. This works well. But ... if the thread do a 
> long sleep [ just before the end of run() ], and the process tries to 
> delete it (calling terminate in the destructor of T), the thread prints 
> out the message and then blocks infinitely. Thus, ending itself works 
> but forcing a thread to terminate does not work. Once again, this bug 
> disappear when using a 2.6.8 kernel !
>
> Have you any idea on why this behaviour ??
>
> Thanx
> S. Domas

dyfet.vcf
Description: Vcard