Re: Object-oriented multithreading
Alan McKenney wrote:
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.
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.
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.
That sounds like synchronized methods in Java. The problem with
applying it unchanged to C++ is, as you noted, that you lose a lot of
flexibility (I think that some additions have been made recently to
Java to supplement synchronized methods). What about non-member
functions? These don't exist in Java, but they do in C++, and it
would be nice to be able to lock them as well (but then what do you
lock?). What if you want a single operation that affects multiple
objects to execute atomically? What about including the arguments
passed to the function in the lock?
Since objects and functions are the units of data and code in C++ it
makes sense to make them units for locking protection as well. What
we need to make it powerful enough is a mechanism for combining these
units. Some way to lock multiple objects, to combine functions in a
way that allows them to use each other's locked data, and so on. But
this is hard to do.
Let's assume a "shared" type modifier, and an "atomic" attribute for
functions. When an atomic function is called, all objects of a shared
type that it accesses are locked before the function is executed. The
problem is that the atomic function may call other functions, which
access different (or the same!) data that may be shared. All of those
things have to be locked as well, _before_ the original atomic
function is executed. So the compiler has to analyse the call graph,
and lock any shared variables touched by the subgraph headed by our
atomic function.
That's hard already, and maybe impossible if you take into account
virtual calls. The second problem is, it may introduce deadlocks.
Suppose we have two shared global objects, and we want to compare
them using an atomic function cmp(), from two different threads:
shared SomeObject a;
shared SomeObject b;
atomic bool cmp(shared SomeObject & const x,
shared SomeObject & const y) {
return x < y;
}
void thread_a() {
if (cmp(a, b)) {
/* ... */
}
}
void thread_b() {
if (cmp(b, a)) {
/* ... */
}
}
Now if cmp() locks the variable referenced by x first, and then the
one referenced by y, then it can happen that thread_a locks a, after
which thread_b locks b, and then both of them wait forever to acquire
the next lock. So, this isn't deadlock-safe, and I don't see an easy
way of making it. You could do so by ensuring that all atomic
functions always lock objects in the same global order, but due to
aliasing that seems to be impractical if not impossible.
I suspect that the next level of abstraction up from simple locks is
full-blown transaction support. I've been wondering if you could make
something workable, using exceptions to provoke rollbacks, and clever
template metaprogramming to get the type system to help as much as
possible. I haven't had time to work on this idea unfortunately.
Lourens
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]