Re: Object-oriented multithreading
Alan McKenney wrote:
Over on comp.std.c++, there's a thread about what form
multithreading support in a future C++ language standard
would take.
One of the big issues is synchronization, especially
of memory reads and writes. For example, if we have
int shared_value = 0;
Mutex shared_value_mutex;
...
void thread_a() {
shared_value_mutex.lock();
shared_value += 10;
shared_value_mutex.unlock();
}
void thread_b() {
shared_value_mutex.lock();
shared_value += 20;
shared_value_mutex.unlock();
}
and we assume that thread_b() starts before thread_a()
finishes, it is conceivable that thread_a() will release
the mutex, and thread_b() will get it, before thread_a's
update of shared_value propagates to the processor running
thread_b.
What makes you assume this? It depends on the system, but Posix
guarantees full memory synchronization in both the lock and the
unlock.
(Keep in mind that in a thread-unaware system, no operation
can be assumed to be atomic.)
Keep in mind, too, that a thread-unaware system doesn't have
mutextes:-).
The only safe way to deal with this is to:
a. do all updates of shared variables via library functions,
in addition to protecting critical sections with mutexes,
or:
b. provide a language-defined way to tell the compiler that
a given synchronization variable or operation protects
a given set of variables.
In reading and thinking about this, it occurs to me
that, in my (possibly limited) experience, synchronization
always comes down to having a single thread be able to make a
set of updates to a set of related variables without another
thread updating the same variables in the meantime.
That's true for some uses. For others, it is a question of one
thread making two series of updates, a first, followed by a
second, and ensuring that no other thread can possibly see the
results of the second series of updates without also seeing
those of the first. In simple terms, if we start out with a and
b equal to zero, then one thread sets a to 1, then b to 1. The
goal is that another thread can never see a equal 0 and b equal
1.
Another way to think of it is that we want some set of
operations to be "atomic" with respect to the variables they
reference/update.
If we think in object-oriented terms,
"set of related variables" = object
"set of updates" = method.
Seen this way, the logical unit of data to protect is
an object, and the logical unit of code for an atomic
operation is a method.
Except that it often doesn't work out that way. You have two or
three objects which must remain coherent amongst themselves, so
your atomicity has to cover several objects.
Following this approach, we would handle synchronization of
operations by declaring a member function "atomic", or have
some sort of lock function that would apply to *this.
The compiler would recognize this construct as meaning that
before a thread could start the function, it would have to
wait:
a. to obtain exclusive access to *this (e.g., by locking an
instance-specific mutex), and
b. for all memory writes to *this to have completed,
or at least to have become visible to this thread.
I don't recall seeing this approach mentioned in this group or
comp.std.c++; I don't follow the multithreading groups closely
enough to know if this has come up there or not.
Has this approach been considered? If so, has it been
discarded as a Bad Idea, and, if so, why?
It's one of the approaches used by Java. One which, in
practice, doesn't seem to be much used, because it is so rare
that an object and a function correspond to the desired
granularity of locking.
The main objection that I can think of that I can't easily
dispose of (to my own satisfaction, at least) is that there
are forms of synchronization that don't easily fit into an
"atomic member function" model.
It obviously can't be the only possibility. Even in Java, you
can also synchronize a block on a separate object. My
experience suggests that at times, in fact, synchronization
doesn't even respect scope (i.e. scoped_lock doesn't work).
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]