jthread deadlock?

[Mihai Surdeanu]

I don't agree.
The wouldlosewakeup mechanism works if interrupts are disabled, if I
get it right. This is a piece of code from interrupt():

*********************************************
 if (intsDisabled()) {
	....
        if (wouldlosewakeup) {
        	write(sigPipe[1], &c, 1);
                bytesInPipe++; 
		....
*********************************************

But interrupts are enabled in handleIO just before select. If a signal
comes after that but before select it's treated normally, not buffered.
Mihai

On Sat, 27 Mar 1999, Godmar Back wrote:

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