jthread deadlock?

[Godmar Back]

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

When thread W is restored, it will enter the select, but at this 
point, there will be a byte to read from the pipe.  This byte was 
written in the SIGIO handler.  Hence, the select won't block and we 
won't deadlock.

	- Godmar


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