Re: Threading issue in next standard
Alan McKenney wrote:
I don't know about anyone else, but when I use
mutexes, I always associate each mutex with a set
of (shared) variables that it controls, so what I would
want is to be assured that all writes to the variables
controlled by this mutex were visible to my
thread before the mutex was considered locked.
In other words, for me, synchronization always
applies to an object or set of objects, not to the
universe of objects.
If I may invent some ill-advised syntax, I'd want something
like
synchronizable group_a { int a; std::string b; MyClass c; };
Good point (and I would back this idea), but this is not compatible with
current common usage patterns.
Consider for example the "producer" thread that adds some object to the
shared queue. For this pattern to work, every new object that is created
by the producer (and it might be created as a dynamic structure on the
free store) needs to be visible to consumer threads, but this visibility
will not be guaranteed if the mutex will be associated with some stable
set of objects - in this case with the queue itself.
Something like this:
Object *p = new Object();
// set up the new object
mtx.lock();
queue.push(p);
mtx.unlock();
above, the object in question was created and constructed *outside* of
the scope of mutex, and the mutex itself is only guarding the queue's
internal stuff. If you associate the mutex with the queue only (and
that's the only thing you can statically declare), then consumers will
see the new pointer in the queue, but not necessarily the object that it
points to. (On the other, hand, if you try to extend the scope of mutex
to cover also the object's construction, it might increase contention.)
I guess it's a common pattern and this patter would break.
Note that above, the pointer indirection might not be so explicit. Think
about std::queue of std::strings. Or std::queue of Persons, where Person
has some std::string attributes.
Of course, we might as well drop our habits and accommodate some new
ones. Hell, we're going to do this anyway. ;-)
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]