gback at cs.utah.edu
Sat Mar 27 14:55:11 PST 1999
I think the wouldlosewakeup flags and the sigPipe mechanism would
handle this. Would you disagree?
> 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.
> Mihai Surdeanu Southern Methodist University, CSE
> (214) 768 - 3054
More information about the kaffe