queue container?

[Jonathan M Davis]

On Wednesday, October 26, 2011 10:21 Steven Schveighoffer wrote:
> On Wed, 26 Oct 2011 12:35:32 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
> > On 10/26/2011 04:36 PM, Steven Schveighoffer wrote:
> >> On Wed, 26 Oct 2011 10:13:06 -0400, Gor Gyolchanyan
> >> 
> >> <gor.f.gyolchanyan at gmail.com> wrote:
> >>> It should have both shared and unshared implementations of methods to
> >>> be a full-fledged container.
> >> 
> >> Maybe, maybe not.
> >> 
> >> I'm reluctant to add a copy of all functions to the containers just to
> >> support shared. We don't have a const or inout equivalent for shared.
> > 
> > Copying all the methods and marking them with shared does not make the
> > code thread safe. The shared and unshared versions would have to be
> > different anyways. There is no way do get something that relates to
> > shared/unshared as const does to mutable/immutable.
> 
> You would mark them shared and synchronized. The shared modifier
> guarantees you don't put unshared data into the container, and the
> synchronized modifier guarantees you don't violate thread safety (as far
> as container topology is concerned at least).
> 
> But the method content would be identical.

That doesn't quite work, because synchronized is supposed to be on the class, 
not the function (at least per TDPL; I don't know what the current behavior 
is). Either everything is synchronized or nothing is. So, I believe that 
unless you want to make the whole thing always synchronized, you need to 
create a wrapper type which is synchronized. Of course, if the wrapper could 
then make the wrapped type's functions shared, then that would be great, but 
that probably requires casting.

- Jonathan M Davis