queue container?

Steven Schveighoffer schveiguy at yahoo.com
Wed Oct 26 13:43:47 PDT 2011


On Wed, 26 Oct 2011 15:33:38 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

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

As long as your lock is on the class, and the data is simple, it should  
work.

Yes, it will be inefficient, but I don't feel it makes lots of sense to  
implement a designed-to-be-shared container with the same API as one  
that's designed-to-be-local container.

I don't yet have enough experience with designing shared containers to  
have much useful input.  But I've used locks to pass data between  
threads.  I know how those work, and the risks involved.

-Steve


More information about the Digitalmars-d mailing list