Re: Single thread vs synchronization
Philipp wrote:
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.
--
Eric Sosman
esosman@ieee-dot-org.invalid