queue container?

[Steven Schveighoffer]

On Wed, 26 Oct 2011 14:41:18 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> 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.

Yes, I remember that in TDPL.  It's not the current behavior anyway  
(synchronized methods still exist).  The idea is though, if the class is  
shared, all methods are synchronized, if it's not shared, no methods are.

I suspect not many have implemented shared classes, because it's not very  
conducive to successful compilation...

> 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.

I don't see much of a point of synchronizing non-shared classes.  Maybe  
synchronized classes should imply that all methods are shared.

-Steve