Nope.... Switched over to the new librxtxSerial.so, but it didn't make
any difference at all.
I still think it's the code I quoted below, especially given that I
known one of the unbound threads from each pair is stuck inside the wait
in the first synchronized block.
If I'm right that a second thread would block on synchronized and never
reach the notifyAll(), that would easily explain two threads per
discovery getting deadlocked in WAIT states.
Doing what I can to try to test my theory...
boB
Johnny Luong wrote:
boB Gage wrote:
Upgraded M4 to M5, but nothing changed. Downloaded source, grabbed
some extra debug and actually have identified the locations the
threads are stuck at.
Of the two threads left behind in each discovery attempt, using M5
line numbers:
* The "idleStatusChecker" thread is inside the Thread.sleep(1000)
call at line 108 of
org.apache.mina.core.session.IdleStatusChecker.java. * The numbered
thread is inside the writeMonitor.wait() call at line 154 of
org.apache.mina.transport.serial.SerialSessionImpl.java
...
I'm new to Java, so might be misinterpreting this.... but, this is
what I see when I search out writeMonitor
class SerialSessionImpl
...
private final Object writeMonitor = new Object();
...
private class WriteWorker extends Thread {
@Override
public void run() {
while (isConnected() && !isClosing()) {
flushWrites();
// wait for more data
synchronized (writeMonitor) {
try {
writeMonitor.wait(); <<<<<<< This is
the wait referenced above (line 154)
} catch (InterruptedException e) {
log.error("InterruptedException", e);
}
}
}
}
}
...
private class SerialIoProcessor implements
IoProcessor<SerialSessionImpl> {
...
public void flush(SerialSessionImpl session) {
if (writeWorker == null) {
writeWorker = new WriteWorker();
writeWorker.start();
} else {
synchronized (writeMonitor) {
writeMonitor.notifyAll();
}
}
}
...
}
All writeMonitor references from the file are included above.
Don't the two "synchronized (writeMonitor)" clauses ensure that no
two tasks can execute the enclosed commands at the same time?
Wouldn't that mean that no one task can notify the other(s) while any
other task is waiting for said notification?? I think it also means
no two classes can get triggered by the same notification (ie. you
couldn't get two waiters, first would wait, rest would block until
synchronized).
boB
PS... Are my messages actually getting through?? I haven't seen a
reply to any of my own queries to this list, but I've been stumped, I
coulda stumped others too. :-)
Hi Bob,
You might want to consider using the rxtx-2.2pre2 binaries available
here:
http://rxtx.qbang.org/wiki/index.php/Download
Best,
Johnny
--
boB Gage
Software Engineer
Merge Healthcare
This message is a PRIVATE communication. This message and all
attachments are a private communication and may be confidential or
protected by privilege. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of the
information contained in or attached to this message is strictly
prohibited. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.
