jthread deadlock?

[Godmar Back]

I think the wouldlosewakeup flags and the sigPipe mechanism would
handle this.  Would you disagree?

	- Godmar

> 
> I think I found another deadlock in jthreads, due to the unprotected
> region in handleIO(). Please follow the next scenario (maybe Godmar has a
> few minutes) and correct me if I'm wrong:
> 
> Consider a simple server application with 2 threads: one dispatcher D and
> one worker W. The dispatcher blocks until a request comes on the incoming
> socket. When this happens, the dispatcher decodes the packet, signals
> the worker, and goes back to waiting on the socket. When signaled, the
> worker performs some Java stuff and waits again on the condition variable. 
> I think the next succession of operations leads to deadlock:
> 
> 1. D signals W with a job.
> 2. D is suspended on the socket 
> 3. W does the job and prepares to wait on the cv
>   3.1. No running thread available, thus W eventually enters handleIO with
>   sleep = 1.
>   3.2. W restores interrupts (blockInts = 0;)
> 
> 	<------- SIGIO caught here
> 
>   3.3. W calls blocking select 
> 
> Since interrupts are enabled when SIGIO is caught, the signal is handled
> by handleIO(false), which resumes D. D decodes the packet and signals W.
> Now, since W was interrupted right before 3.3, it will be resumed
> before entering a blocking select, which blocks the whole thing, assuming
> that no other request arrives.
> If this is correct, anybody sees a solution to the problem? 
> I'm using one of the (pretty) recent snapshots on Linux RH 5.2. I checked
> the handleIO code from today's snapshot and the problem seems to still be
> there, it's just acknowledged with some comments (/* NB: BEGIN unprotected
> region */).
> Please don't ask for a test case. My project is a bunch of changes to
> Kaffe and some Java programs not entirely working yet.
> 
> Regards,
> Mihai Surdeanu		Southern Methodist University, CSE 
> 			(214) 768 - 3054
> 
>