At 12:02 AM 4/16/00 +0100, you wrote:
>I've hit a bit of a problem with thread debugging.
>
>It seems to be more philosophical than technical per se....
>
>I'm sending it to the list so that people can tell me that I'm dumb
>and there's an easy way to do it or Paul can muse on it as he produces
>the next versions.
>
>
>The problem is with debugging producer-consumer situations.
>
>Paperclips has a classic P-V setup. The V is a pool of threads
>accepting connections (from the P) over a queue.
>
>The V's sit on the queue with:
>
> queue.wait()
>
>The P call's:
>
> queue.notify()
>
>when it has added something to the queue.
>
>
>The problem is though that when the call
>
> P:queue.notify()
>
>is made it's impossible to tell which V picked it up (only one does
>as per spec).
>
Hi Nick,
I assume that each consumer thread has a call to queue.wait() that suspends
the thread. So why not set a breakpoint at the next line, i.e.,
...
while (true) {
queue.wait(); <= wait for work
doWork(); <= set breakpoint here
}
...
JDEbug breakpoint messages specify the thread on which the breakpoint was
hit. So this should tell you which thread is processing the most recent
addition to the queue.
The above analysis probably oversimplifies the problem
It would be helpful if you could supply a skeleton implementation of the
P-V pattern that I could run to get a better feel for the problem.
- Paul
------------------------------------------------------------
TECH SUPPORT POLICY
I respond only to requests that contain a complete problem report. The
easiest way to ensure that your report is complete is to include the output
of the JDE->Help->Submit Problem Report command in your request.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JDE website: http://sunsite.auc.dk/jde/
JDE mailing list archive:
http://www.mail-archive.com/[email protected]/maillist.html
