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