queue container?

[Gor Gyolchanyan]

Not necessarily. You don't even need to have the entire function
synchronized. You can define your own synchronization blocks, using
the object's or classes monitor.

On Wed, Oct 26, 2011 at 10:41 PM, 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. 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
>