Question: Waiting for multiple Objects

[Günther Stößl]

Hello,

I am porting programms from Windows to Java.
No I am stuck with following problem:

In these applications following scenario is often used:

Main working Thread waits on several socket channels for arrival of
data but uses also a lot of semaphores to notify about messages from
other threads:
Channel data and semaphores are combined in one call to
WaitForMultipleObjects.

With java.nio I can use selectors for the channel data, but I see no
possibility for parallel waiting on other Objects.

Even with Doug Leas java.cocurrent library I dont see how to solve
above problem

Does somebody jave ideas how above problems can be solved ?

Thanks
Günther

 

[Knute Johnson]

Hello,

I am porting programms from Windows to Java.
No I am stuck with following problem:

In these applications following scenario is often used:

Main working Thread waits on several socket channels for arrival of
data but uses also a lot of semaphores to notify about messages from
other threads:
Channel data and semaphores are combined in one call to
WaitForMultipleObjects.

With java.nio I can use selectors for the channel data, but I see no
possibility for parallel waiting on other Objects.

Even with Doug Leas java.cocurrent library I dont see how to solve
above problem

Does somebody jave ideas how above problems can be solved ?

Thanks
Günther

1.5 has a Semaphore class?

 

[Thomas Hawtin]

With java.nio I can use selectors for the channel data, but I see no
possibility for parallel waiting on other Objects.

You can wakeup the thread waiting on the selector.

http://download.java.net/jdk6/docs/api/java/nio/channels/Selector.html#wakeup()

Tom Hawtin

 

[John C. Bollinger]

1.5 has a Semaphore class?

As a matter of fact, yes: java.util.concurrent.Semaphore. There are a
lot of other interesting goodies in java.util.concurrent as well. If
mention of a Semaphore class turns your head, then you'll definitely
want to take a look.

 

[Chris Uppal]

Main working Thread waits on several socket channels for arrival of
data but uses also a lot of semaphores to notify about messages from
other threads:
Channel data and semaphores are combined in one call to
WaitForMultipleObjects.

I think you'll have to change your design. Or rather, change how your design
is expressed as code.

In your Windows program, you had a logical structure where the main thread was
waiting for any one of several events -- input available, a different thread
finishing a subtask, an externally supplied shutdown request, whatever. So
/logically/ it was waiting on a queue of notifications. It looped, sleeping
until there was something on the queue, and then pulling it off and handling it
appropriately. The other threads, including the IO (which as an implementation
detail happened not to require explicit separate threads) would get on with
their stuff, and when they had something interesting, would post notifications
to the queue. The main thread would then wake up and deal with whatever had
just happened.

In your Windows code, that structure was obscured, since you could use
WaitForMultipleObjects() to handle the queuing/notification stuff somewhere
hidden inside Windows.

In Java there isn't such a (slightly hacky) general-purpose wait function. So
you'll have to make that aspect of the design explicit and create a real
notification queue. An actual object. Maybe your Windows code would have been
better (clearer) if you had done the same there, I don't know (but I do suspect
it ;-). In Java you don't have a choice.

BTW, you'll have to use an extra slave thread to do the waiting-on-IO-channels
bit of it. That can wait blocked on the channels, and post notifications (with
or without the accompanying data according to taste) to the main thread just
like any other helper thread.

Once you have that structure set up, it may be that more opportunities for
abstraction become obvious. For instance you might be able to remove any
hard-wired test-and-branch that decodes each notification and decides what to
do with it. Another possibility is that you might be able to abstract away the
decision to have a single "main" thread waiting on the queue and a larger
number of helpers putting things on it, and instead make the mapping of threads
to activities be more flexible. But that's all speculation...

-- chris