fully cancelable

[Jan Burse]

Dear All

I am checking how I could code fully cancelable
blocking methods. i.e. they should cancel when
I call interrupt once.

Assume I have a method as follows:

void bla() {
synchronized(lock) {
A;
while (!cond) {
wait();
}
B;
}
}

I could simply swallow the InterruptedException from
wait. Now if I catch it, I can rethrow it or set the
interrupt flag again via interrupted. So my first idea
was as follows:

void bla() {
synchronized(lock) {
A;
while (!cond) {
try {
wait();
} catch (InterruptedException x) {
C; /* some clean up */
Thread.currentThread().interrupt();
return;
}
}
B;
}
}


But my conclusion so far that this is not fully working.
Since during A, cond and B also the interrupt flag could
be set, and if I don't check it, I will enter wait and
block infinitely, although interrupt was called once.

void bla() {
synchronized(lock) throws InterruptedException {
A;
while (!cond && !Thread.currentThread().isInterrupted) {
try {
wait(1000);
} catch (InterruptedException x) {
Thread.currentThread().interrupt();
}
}
if (Thread.currentThread.interrupted()) {
C; /* some cleanup */
throw new InterruptedException();
}
B;
}
}


So I need to use a wait() with a timeout parameter, otherwise
the interruption might get unnoticed. Right?

Bye

 

[Lew]

So I need to use a wait() with a timeout parameter, otherwise
the interruption might get unnoticed. Right?

The book /Java Concurrency in Practice/ by Brian Goetz, et al., covers this in
detail.

 

[Jan Burse]

The book /Java Concurrency in Practice/ by Brian Goetz, et al., covers
this in detail.

What does it cover exactly? In which section?
I don't have a copy at hand.

Bye

 

[Jan Burse]

It covers what you need to know to write correct parallel programs in
Java. Given the types of issues you have been asking about, if you don't
have a copy you need to get one and read it.

Patricia

Actually I was reading the C source (*) of wait (windows, unixes),
and got what I need to know. Both implementations clear the
interrupted flag first:

340 /*
341 * Atomically drop mutex and wait for notification.
342 */
343 int
344 sysMonitorWait(sys_thread_t *self, sys_mon_t *mid, jlong millis)
345 {
346 if ( sysThreadIsInterrupted(self, 1) ) {
356 return SYS_INTRPT;
357 }
358

Reason in windows implementation is clear, since same handle
is used to signal notify(), notifyAll() and interrupt(). So
internally sysThreadIsInterrupted() does a ResetEvent() on this
handle. But strangely linux implementation puts some mutex
inside sysThreadIsInterrupted(), whereas windows does not!

Be it as it is, so one answer is simple:

> be set, and if I don't check it, I will enter wait and
> block infinitely, although interrupt was called once.

No, wait() will not block infinitely, since it will also
throw an InterruptedException when the isInterrupted()
was initially true before wait() was called. This was not
clear to me, and I cannot deduce it from the wait() API
documentation, since it writes:

If the current thread is interrupted by another
thread *while* it is waiting, then an InterruptedException
is thrown.

Do all Java implementation instead implement a *while or before*?

Best Regards


(*)
http://hg.openjdk.java.net/jdk6/jdk6-gate/jdk/file/9ec468ac80d0/src/windows/hpi/src/monitor_md.c

 

[Jan Burse]

Forget the source; read the spec.

-- chris

Well my starting point was the spec:

> If the current thread is interrupted by another
> thread *while* it is waiting, then an InterruptedException
> is thrown.
>
> Do all Java implementation instead implement a *while or before*?

But the above is from JDK 1.4. I just see that it was
corrected for JDK 1.6:

If the current thread is interrupted by any thread *before
or while* it is waiting, then an InterruptedException
is thrown.

Oho, interesting...

Bye

 

[Arne Vajhøj]

Well my starting point was the spec:


But the above is from JDK 1.4. I just see that it was
corrected for JDK 1.6:

For Java you can only assume that the spec will be followed.

If you write code for OpenJDK 1.6 build XXX on platform Foobar,
then you can see how it is implemented there.

But you can not assume that it will be the same for Java from
a different vendor, for a different version or for a different
platform.

Arne

 

[Arne Vajhøj]

BTW you are all talking about spec. What do you mean exactly
by spec? The wording in some Javadoc, or something else?

spec = JLS + JVM spec + Java Doc + various sub spec like JDBC

Arne

 

[Lew]

I was thinking primarily of:

The Java Language Specification
Third Edition

(or a later edition if one has appeared -- I'm still in catch-up mode on recent
developments in the Java world)

And:

The Java Virtual Machine Specification
Second Edition

(with the same caveat). Actually, as I remember it, the JVM spec doesn't have
a lot to say about synchronisation issues, but it's part of what I mean when I
talk about "the spec" anyway.

Both are [I assume, still] available free on the Web.

The JLS spec is the more relevant, and its link was posted about 11 hours
before your post.

The basics of Java will be achieved after having studied the tutorials, the
JLS, the book /Effective Java/ by Joshua Bloch for general Java programming
and /Java Concurrency in Practice/ by Brian Goetz, et al., for concurrency
mastery. Jan should study those sources, and definitely must own those two
latter books. My copies are well thumbed and coffee stained, and getting more
so all the time.

 

[Jan Burse]

Go thou and buy the book recommended upthread.
http://www.javaconcurrencyinpractice.com/

There are other sources:
http://www.ibm.com/developerworks/java/library/j-jtp05236.html

Don't delay. Do it now.


http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#stop()

You aren't going to master Java concurrency by random ill-considered
questions on Usenet. Do the fundamental research.

I guess you are not in helping mode right now. Instead
you decorate your posting with stupid appelations, which
cost you nothing, since you don't do real research for
helping out. Just lists of suggestions, piles of book
references, bla bla, ... So cheap.

All the work I have to do by myself. Interestingly the
JLS has practically a procedural description of wait(),
which implies the *before or while*. It says(*)

Before step 1:
If thread t is interrupted, an InterruptedException
is thrown and t's interruption status is set to false.

So this matches pretty much the implementations I saw, but
only a few of the Javadocs.

Next time guys, please show a better performance. Otherwise
I will think this newsgroups is not a hangout were from
time to time experts give a good response, but rather a
hangout for nothing than a*******.

Best Regards

(*)
http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.8.1

 

[Lew]

I guess you are not in helping mode right now. Instead

What is more helpful than showing the source material for the answers to your
questions?

you decorate your posting with stupid appelations [sic], which
cost you nothing, since you don't do real research for

If by "stupid appellations" you mean the links to that source material, those
are there to help. Of course I do "real research" - that's how I know that
these sources will help you most.

You're acting like a child who wants candy and is angry that all you got was
five dollars and a ride to the candy store.

helping out. Just lists of suggestions, piles of book
references, bla bla, ... So cheap.

I truly am mystified by this response. I cannot imagine what you're here for
if not suggestions, book references, free web-site references, explanations of
how they're relevant with pointers to more information, "bla bla".

All the work I have to do by myself. Interestingly the

You would have to do much less work if you did the suggested reading.
"Measure twice, cut once."

JLS has practically a procedural description of wait(),
which implies the *before or while*. It says(*)

Before step 1:
If thread t is interrupted, an InterruptedException
is thrown and t's interruption status is set to false.

So this matches pretty much the implementations I saw, but
only a few of the Javadocs.

Next time guys, please show a better performance. Otherwise

Ooh, now you're scolding us! I feel sooooo chastised!

I guess you're not in appreciation mode.

I will think this newsgroups is not a hangout were from
time to time experts give a good response, but rather a
hangout for nothing than a*******.

Goodness, me! Aren't you in a bit of a snit! Tch, tch.

I guess you're not exactly a devoté of Dale Carnegie.

Dude, all the information you got was helpful and given with intent to assist.
The references for further research are very valuable, especially taken in
context of the specific responses also provided. As a group, the newsgroup
has fully answered your questions. You didn't answer many of ours. If you
think insulting all these people who've donated their thought and advice to
your cause will help you, you are mistaken.

Your mean-spirited response is very much out of place.

 

[Arne Vajhøj]

I guess you are not in helping mode right now. Instead
you decorate your posting with stupid appelations, which
cost you nothing, since you don't do real research for
helping out. Just lists of suggestions, piles of book
references, bla bla, ... So cheap.

Some people think that they can learn complex matters
without working hard reading.

They are wrong.

All the work I have to do by myself.

Of course.

Otherwise you would not learn anything.

Next time guys, please show a better performance. Otherwise
I will think this newsgroups is not a hangout were from
time to time experts give a good response, but rather a
hangout for nothing than a*******.

It is a common characteristic by incompetent people that
they don't take good advice.

Arne

 

[Jan Burse]

Dude, all the information you got was helpful and given with intent to assist.

No, you are mistaken, nothing you posted in this thread was helpful.
And when I am posting here I am not asking for assistance, but for
opinions.

Best Regards

 

[Arne Vajhøj]

No, you are mistaken, nothing you posted in this thread was helpful.
And when I am posting here I am not asking for assistance, but for
opinions.

When you post to a public forum then people answer with what
they consider relevant.

As far as I can tell, then you got both assistance and
opinions.

Apparently you did not like either.

But that is your problem.

Arne

 

[Mike Schilling]

..

Here's what I'm seeing.

** You have posted questions, without posting sufficient information to
help us give you the answers (or opinions) you're looking for.

To me, this is the main point. It's a very complicated and involved
subject: asking unmotivated point questions does not communicate what it is
that you really need to learn. That's the reason I didn't try to answer:
anything I said, even if factually correct, was going to be misleading.

 

[Arne Vajhøj]

.

To me, this is the main point. It's a very complicated and involved
subject: asking unmotivated point questions does not communicate what it
is that you really need to learn. That's the reason I didn't try to
answer: anything I said, even if factually correct, was going to be
misleading.

Complex problems can be very difficult to describe in
a question within the length that people are willing
to read.

But if OP did his/her best in the original question and
listen to the comments provided, then I am not so afraid of
making a few guesses.

Arne

 

[Richard Maher]

Hi Patricia,

On 12/27/2010 9:02 AM, Jan Burse wrote:
...
...

You have found the answer to one question that you thought to ask. What
about all the questions you have not thought of?

Normally, I prefer to work things out for myself from the primary
documents, such as the JLS. However, there are many, many ways of
writing concurrent Java programs that have subtle, hardware dependent,
intermittent bugs.

I came to this issue with a background that includes many years of Java
programming, compiler writer experience reading language specifications,
and multiprocessor server architect understanding of caches and memory
model issues.

Despite all that, I learned a lot by reading "Java Concurrency in
Practice", including answers to questions I would not have thought of
until I found an intermittent bug in one of my programs. Although most
of the information in it could be deduced from the JLS and API
documentation, reaching all the conclusions would be a lot of work, with
a high risk of missing something.

In my opinion, reading that book is the most efficient way of learning
how to write solid concurrent programs in Java, much more efficient than
doing all the work yourself, duplicating the analysis that went into it.

Given your threading experience, and that of others participating here, I
guess we should be able to wrap this up before lunch: -
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7001755

A JAVA threading bug that could effect all LiveConnect users while being
ostensibly school-boy in nature surely must be a doddle for this assemblage?

I'm also sure Jan would be interested in a practical demonstration. Me? I'd
be happy with the odd one of you, who may not know the answer, incrementing
the bug vote-count. Or even a pointer to the thread-pool work allocation
algorithm in the docs/specs somewhre would be really useful!

Patricia

Cheers Richard Maher

 

[Jan Burse]

I'm also sure Jan would be interested in a practical demonstration. Me? I'd
be happy with the odd one of you, who may not know the answer, incrementing
the bug vote-count. Or even a pointer to the thread-pool work allocation
algorithm in the docs/specs somewhre would be really useful!

You are saying it hangs in the bug report. It would be of interest
to see in which configuration it hangs, by doing a thread dump.

The tread dump will list all threads, and their waits. You can
directly see deadlocks, eventually starvations, etc..

I don't know how to do such a snapshot in a browser context.

Bes Regards

P.S.:

Here you see an example snapshot of a blocking read,
simply press Ctrl-Pause (the docu says, I did it from
and IDE) (BTW, wait and locked on same object is no
problem, locked just means you have entered the monitor,
but control of the monitor is released by the wait and
later regained):

[...]

"Thread-3" prio=6 tid=0x046a6400 nid=0x174c in Object.wait() [0x055bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x1ec62190> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at omonia.util.comp.InputReader.read(InputReader.java:119)
- locked <0x1ec62190> (a java.lang.Object)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.read(BufferedReader.java:157)
- locked <0x1ec62198> (a omonia.util.comp.InputReader)
at matula.util.text.Linespro.next(Linespro.java:159)

[...]

 

[Jan Burse]

You are saying it hangs in the bug report. It would be of interest
to see in which configuration it hangs, by doing a thread dump.

I have just glossed your code. And I have now
a hypothesis where a the hang could happen. In
your code I see the following (both of course
inside a monitor over lock):

A:
lock.wait()


B:
lock.notifyAll();


Now if it happens that B reaches the notifyAll()
before the A reaches the wait(), well then
you will get a hang.

You might eventually recode your example
as follows, or in the spirit of the following
code snippet (again inside a monitor
over lock):

A:
while (!hitMe) {
lock.wait();
}
hitMe=false;


B:
hitMe=true;
lock.notifyAll();

Such a piece of code will be immune on the
timing when wait() or notifyAll() is reached.

Bye

 

[Richard Maher]

Hi Jan,

Thank-you for your reply and interest in the LiveConnect bug.

I have just glossed your code. And I have now
a hypothesis where a the hang could happen.

No need to hypothesize! That's why I provided the SSCCE that is much
heralded here in cljp. Easy to compile, easy to run, easy to reproduce.
Funny thing is, once I responded with the SSCCE, evryone went quiet :-(

In
your code I see the following (both of course
inside a monitor over lock):

A:
lock.wait()


B:
lock.notifyAll();


Now if it happens that B reaches the notifyAll()
before the A reaches the wait(), well then
you will get a hang.

Yes, but you left out a very important: -
"queue.put(callback);"

the notifyAll() cannot occur until the consumer thread gets what's been put
and only after obtaining the lock that is held by the producer until after
the put has been completed.

It might help to think of all this as a synchronous Write ('cos that's
exactly was is being implemented)

Once again, very little code, very easy to reproduce and observe, very
little need for guesswork from the self-proclaimed illumni present here
today.

Bye

Cheers Richard Maher

 

[Richard Maher]

Hi Chris,

Jan's right of course. I just want to point out a couple of other
oddities which /may/ be affecting you.

Utterly trivial point mentioned just for completeness: declaring the
ArrayList windows as volatile achieves exactly nothing.

You getNum() method is synchronized, that means it will be holding a lock
on "this" for the duration of it's execution.

Yes, by design.

Since that method synchronizes on the "lock" object too, that means that
you will be locking two objects at the same time.

Yes by design. (And I'm sure you notice the scoping differences of the
objects being locked)

That isn't /necessarily/ a problem, but it often is unless you've designed
for it specifically.

See above.

Also, it means that it will be holding the lock on "this" while it is
sleeping waiting to be notified on "lock" (the lock on "lock" will be
released during the wait(), but the lock on "this" won't).

Which is why the setBack() method is not synchronized. It's a callback! (But
then I'm sure you noticed that too)

I doubt if that is what you want.

You are wrong.

In particular, a call to destroy() will block (as I read the code) if
there is an ongoing call (sleeping) to getNum().

If your Aunt had balls she'd be your Uncle.

To add to the urgency of Jan's point: the call to queue.put() is blocking,
so your thread may sleep (still holding /both/ locks!) while it's
put()-ing the next object. During all of that time it is vulnerable to
the race-condition that Jan described.

I disagree with Jan but am very happy to be shown the error of my ways.

I don't really understand your overall logic, which has to be partly
because I don't follow what your JavaScript is doing (my JS is weak and my
LiveConnect is non-existent), and may also be because the effect of
cutting down real code to make a SC*E can easily make sensible code look
as if it's doing stuff pointlessly.

This *is* the SSCCE! The real code is much more complex amd volumous.

Still, it does seem odd to me that you have (if I've not missed something
in your code) a worker thread which just puts stuff onto a blocking queue,
and then sleeps waiting to be notified. The first question is "notified
of what?".

That the I/O is complete (if you must know as Isaid this is a SSCCE.

But another question is what is the thread /for/ ? It seems that the
supplier of the next lump of data (the "callback" JSObject) could just put
the object onto the queue directly ? (It does mean that if the queue is
full then it is the worker thread that gets blocked, not the ultimate
supplier of the data, but doing things this way in effect just increases
the capacity of the queue by one. If the queue is full and you try to add
two things to it then one of the original callers will be blocked because
the worker thread can only "do the waiting" for one of them. Simpler just
to use a slightly bigger queue...)

Look this is the greatest news for JAVA on the Web since it's GUI
capabilities were deserted in favour of Javascript,CSS,HTML5, and Flash but
the jaded and cynical "we're only on the server now" crowd here refuse to
embrace the possibility of JAVA on the web as faceless infrastructure
middleware. What my code seeks (and comes damned close(there are *many*
issues other than this)) to do is multiplex background task output to
multiple tabs [a]synchronously.

This is exciting! This is very worthy of investment! This is certainly
worthy of more than a priority 4 and 4 votes on a seemingly
Oracle-depracated bug-tracker :-(

But sadly, this post, like others, will invite typical "Well you shouldn't
be doing that anyway" or "If God wanted us to fly he would've given us
wings" responses from the usual wanker(s).

I dunno if any of that will help with your bug, but there are a good
couple of hour yet till lunch-time ;-)

Cricket's finished (early again - oops) so I'll try to get Jan that
thread-dump from the Java console.

-- chris

Thanks for your interest/help.

Cheers Richard Maher