Java Timer

[Chris Smith]

Now - I have never done any significant multithreaded Java application. Is
it possible to interrupt sleep directly without killing the thread, or is
there a better function to use? (I know in MFC C++ there were Semaphores
and mutex objects, and you could wait for them to be in a triggered state.)

I don't remember enough of MFC to recall exactly how MFC wrapped the
Windows API here. As far as the API itself, though, the equivalent to
Win32 mutexes and critical sections are synchronized blocks, used in
different ways. The equivalents of events are Object.wait and
Object.notify (as implemented in certain ways, and of course combined
with synchronized blocks as they always are).

Semaphores are slightly more complex and not available directly in the
language, but they can be easily built from the monitor functions above.
Beginning with Java 1.5, the java.util.concurrent package contains an
implementation of semaphores. Also, Java 1.5 contains an implementation
of mutexes (known as locks) that are NOT tied to lexical scope in the
language in the manner that synchronized blocks are.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

If my ignorance is obvious you can tell me to shutup . . but . . .

I followed you up until this point "that are NOT tied to lexical scope in
the language in the manner that synchronized blocks are."

No problem. With synchronized blocks, you are required to designate a
block in which a monitor/lock is acquired. That block is either a whole
method or some block within that method. When the block is entered,
then monitor is acquired; and when you leave, the monitor is released.
This is somewhat convenient because you can't forget to release the
monitor.

However, it's also slightly limited. Imagine, for example, that I'm
implementing an interpreter for some scripting language. Imagine that
the scripting language has explicit commands called "lock" and "unlock"
that acquire and release monitors. I can't implement this with simple
synchronized blocks in Java, because when I release the monitor depends
on some future user input, and NOT on when I leave a block of Java code.
Using locks from Java 1.5's java.util.concurrent.locks package, though,
I can do this. I just call lock() in response to the lock operation and
unlock() in response to the unlock operation. Poorly formed script code
can lead to forgetting to release a lock, but that is the script's
problem, not mine.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Luc The Perverse]

No problem. With synchronized blocks, you are required to designate a
block in which a monitor/lock is acquired. That block is either a whole
method or some block within that method. When the block is entered,
then monitor is acquired; and when you leave, the monitor is released.
This is somewhat convenient because you can't forget to release the
monitor.

However, it's also slightly limited. Imagine, for example, that I'm
implementing an interpreter for some scripting language. Imagine that
the scripting language has explicit commands called "lock" and "unlock"
that acquire and release monitors. I can't implement this with simple
synchronized blocks in Java, because when I release the monitor depends
on some future user input, and NOT on when I leave a block of Java code.
Using locks from Java 1.5's java.util.concurrent.locks package, though,
I can do this. I just call lock() in response to the lock operation and
unlock() in response to the unlock operation. Poorly formed script code
can lead to forgetting to release a lock, but that is the script's
problem, not mine.

LOL. I thought I had accomplished something when I made a C++ class that
tied a Mutex object to a lexical scope - not the other way around

I can see where both could be useful however.

Oh BTW I get it now