SOURCE "Alexander Terekhov" <terekhov@[...].de>  wrote in message
news:3F7BD923.727F1424@[...]..
> 
>  Andrei Alexandrescu wrote:
>  [...]
>  > "Nope" like in, "Nope, I don't understand"?
>  >
>  > > >   b. Some infrastructure similar to his LockingPtr
>  > >
>  > > Nope.
>  >
>  > Idem? :o)
> 
>  Volatiles aside for a moment, I don't believe in locking_ptr usefulness.

I understand. Let me give and ask for some more detail here.

What locking_ptr does is to provide access to an object's member functions.
The object is passed around in the form of volatile pointers or references,
and what locking_ptr does is to cast away the volatile *in conjunction with*
locking that object's mutex. This way the type system knows what the
programmer knows - that the object is locked. I consider this a good
principle to follow in general, and the damned volatile is what puts that
principle to work in the context of locking.

Now, in its unlocked state, the object might have a smaller interface (a set
of volatile member functions) or no interface at all, thus making any member
function call a compile-time error. It is up to the class designer to define
which subset of a class' interface makes sense to expose to clients when the
object is unlocked. The class designer can double the member functions of
the object (locked and unlocked versions) or can leave zero unlocked
versions. I consider that a nice feature.

Similar constructs and patterns have been provided before for C++ (notably
Doug Schmidt), but none that I know offers the same amount of static
checking, or offer it at the expense of writing much more code. I believe
that distinguishing between the locked and unlocked state of an object with
a type qualifier is an interesting idea. Cormac Flanagan
(http://research.compaq.com/SRC/personal/flanagan/home.html) has developed a
number of extensions to Java that promote the same idea - enforcing locking
constraints through type modifiers.

Now you might not agree with the model of object-level locking, and indeed
it falls short for transactions involving multiple objects. Is that the
case? In that case locking_ptr can never have any value because it helps
object-level locking only.

>  BTW, for some reason, google doesn't show your reply to the following
>  posting:
> 
>  http://groups.google.com/groups?selm=94ccng%24m2t%241%40nnrp1.deja.com
>  ---
>  From: Aleksey Gurtovoy (alexy@meta-comm.com)
>  Subject: Re: volatile, was: memory visibility between threads
>  ---
> 
>  DMCA takedown, perhaps. ;-)

Heh heh. Or maybe I didn't answer because I thought those points have been
addressed in other postings in the same thread?


Andrei



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost