Single thread vs synchronization

[Philipp]

Hello
I want to make an existing library thread-safe as it is now accessed
through several threads.
The work in the library is done by a single internal thread. External
events to be processed are posted to a blocking priority queue and
then taken up by that internal thread in the lib. This part is thread
safe.
I also have getters to read the present state of the lib and setters
to set parameters which define how the events are treated. Both of
these are accessed by several threads and not yet thread safe.

In order to make these safe, I see two possibilities (please comment
if others exist).

1. Protect the accessed fields with synchronisation.

2. Make all requests into Futures which are posted to the queue and
are processed by the internal thread.

What are the pro's and con's of the two approaches?

In particular regarding:
- throuput
- ease of developing non-deadlocking code
- possibility to increase the number of "worker" threads later on

Thanks for your input
Philipp

 

[Eric Sosman]

Hello
I want to make an existing library thread-safe as it is now accessed
through several threads.
The work in the library is done by a single internal thread. External
events to be processed are posted to a blocking priority queue and
then taken up by that internal thread in the lib. This part is thread
safe.
I also have getters to read the present state of the lib and setters
to set parameters which define how the events are treated. Both of
these are accessed by several threads and not yet thread safe.

In order to make these safe, I see two possibilities (please comment
if others exist).

1. Protect the accessed fields with synchronisation.

Won't work -- not all by itself, anyhow. If the library
is running a computation on behalf of thread T1 and thread T2
starts changing the parameter values, the fact that the changes
themselves are synchronized is of no help. And after the work
is finished and T1 is using the getters to find out how things
went, it will be retrieving information not about its own
computation but about T2's computation now in progress.

2. Make all requests into Futures which are posted to the queue and
are processed by the internal thread.

This is the way to do it, whether you use Future or roll
your own. Either way, you need to separate the "job ticket"
and "work product" from the library itself, putting them in
a separate object (or objects) that the library's customers
can manipulate.

What are the pro's and con's of the two approaches?

One works, one doesn't.

In particular regarding:
- throuput

Limited by the single-threaded nature of the library.

- ease of developing non-deadlocking code

Mu.

- possibility to increase the number of "worker" threads later on

A framework organized around Future or something like it
will experience very little disruption if the single-threaded
"server" becomes multi-threaded.

 

[Philipp]

     Won't work -- not all by itself, anyhow.  If the library
is running a computation on behalf of thread T1 and thread T2
starts changing the parameter values, the fact that the changes
themselves are synchronized is of no help.  And after the work
is finished and T1 is using the getters to find out how things
went, it will be retrieving information not about its own
computation but about T2's computation now in progress.

Thank you for your valuable response.

Yes you are correct, the synchronization must be pretty low-level and
exclude any interaction on the system while any other thread is acting
on it (get or set or processing event). But I believe now that this
would result in a big mess. Each entry point to the lib must sync on
the same lock. So I will definitely follow your advice and use the
internal queue...

     This is the way to do it, whether you use Future or roll
your own.  Either way, you need to separate the "job ticket"
and "work product" from the library itself, putting them in
a separate object (or objects) that the library's customers
can manipulate.

Yes my calculation and getters will return mostly primitive values or
immutable objects. So I'm pretty safe on that side.
Are you suggesting to not use Future but make something up myself?
Why?

This approach seams very close to Swing's invokeLater(). Are there any
common pitfalls that I should know about?

Thanks Phil