queue container?

[Timon Gehr]

On 10/26/2011 07:21 PM, 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.
 >
 > -Steve

And sometimes it will even work.

But synchronization=locking is inefficient and does not work in the 
general case (starvation, dead lock), and if it does, it is very hard to 
prove correct. The design and implementation of efficient shared 
containers with strong correctness and liveness guarantees is way more 
involved than simply putting synchronized on an existing class whose 
implementation worked well for serial computing. (but I am sure you know 
that)