Inter-thread communication design question

[Chris Cornell]

Hello all,

I have a question regarding the design pattern and implementation
details of coding a system that allows for simple and efficient
inter-thread communications from the perspective of a design pattern
approach. I'm trying to get a better understanding at designing my
java programs in a more modular fashion that can support a high level
of concurrency when needed.

Suppose I have class A that is composed of 2 different data structures
(as classes themselves) that I use frequently and need to be
synchronized (or updated with data) from an external source such as a
database, etc..

class A {
B _b;
C _c;
}



_b and _c should be updated behind the scenes on its own without
implementing any of the updating or housekeeping inside class A,
therefore _b and _c should be fully self-contained.

Sometimes however, maybe due to unforseen external events or by user
request, class A will get a request to explicitly have the data in _b
or _c updated. Since _b and _c are threads, how can I communicate
with _b and _c asynchronously to tell them to update themselves
without blocking the instruction pointer in class A.

Right now I implemented class B and class C as Runnable and in the
run() function i have it sleep(500) and check for an update flag...
etc.. well, it's not a very good implementation to say the least...

should B and C be implemented this way:

implement as a normal class (not thread or runnable) and have an
update() method in it that spawns code as a thread: ie, new Thread(
new Runnable() { ... } ); and have that set a boolean write-lock
flag on the data (or however the locking mechanism may be
implemented). So that way, I can just call update from wherever and
it will synchronize itself as needed.

There's also the possibility that _b might have to tell class _c to
update itself, etc.. or maybe some inter-class-inter-thread locking.



Any input on a good design and semantic implementation on this sort of
problem would be most appreciated.


Thanks in advance,


Chris

 

[FISH]

Hello all, [snipped...]

Right now I implemented class B and class C as Runnable and in the
run() function i have it sleep(500) and check for an update flag...
etc.. well, it's not a very good implementation to say the least...

should B and C be implemented this way:

implement as a normal class (not thread or runnable) and have an
update() method in it that spawns code as a thread: ie, new Thread(
new Runnable() { ... } ); and have that set a boolean write-lock
flag on the data (or however the locking mechanism may be
implemented). So that way, I can just call update from wherever and
it will synchronize itself as needed.

There's also the possibility that _b might have to tell class _c to
update itself, etc.. or maybe some inter-class-inter-thread locking.



Any input on a good design and semantic implementation on this sort of
problem would be most appreciated.

There are probably a number of ways of doing this... Here's an
efficient (the most efficient?) one:-

Using the thread tools provided by the JVM: B and C are threaded, and
synchronized on themselves (they use themselves as the mutex lock
object). Their run() method wait()'s, which puts their thread into
a blocked state and releases their lock. When the external thread in
class A wants to prompt them to update their data, it acquires the lock
and calls notify(), thus: synchronized(_b) { _b.notify(); }

Nofitification wakes up the waiting thread, and once the A thread
has exited its synchronized block, the revived thread will be free
to re-acquire its own lock and carry on. Obviously run() is in a
loop, so once the work is done it wait()'s again - blocking until
the next time it is prompted to update the data.

If the accessor methods of B and C are also synchronized to the same
lock, then they will be stalled while the lock is held by B's run()
(...or indeed during the brief time A is in the synchronized block).
So access to the data can never happen when it is being updated.

Now, you say that B and C can update "on their own" and "behind the
scenes"... but you don't explain how this happens or how the class
knows when to update. Even so, this doesn't matter - simply add a
second thread (another inner class) to B and C which monitor for
updates, and then they themselves call notify() - in the same way
that external classes do.

To recap: you have an infinate loop which updates, with a wait() in
it to make the thread block. Other threads (inside or outside of
the same class) may call notify() to wake up this thread. The
wait/notify mechanism in Java knows how to work with locks - all
that is required is you synchronize any data accessor methods to
the same lock.

One final note: if you want B and C to be tied, that is to say
that access to both sets of data is forbidden when either one is
in an 'updating state', use a separate object as the mutex lock
in both classes. This can be anything - for example just an
Object instance which has no other purpose than to be used as a
communal lock between both classes - allowing them both to be
locked and unlocked at the same time.

-FISH- ><>