mihai at seas.smu.edu
Sat Mar 27 14:32:06 PST 1999
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
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