Re: Container libraries

[Simon Wright <simon@pushface.org>]

nma124@hotmail.com (steve_H) writes:

> Hyman Rosen <hyrosen@mail.com> wrote in message  
> 
> > People usually want the wrong sort. If someone needs to access
> > a container simultaneously from multiple tasks, then they should
> > privide the synchronization, not the container. 
>  
> But this way you will have duplication of effort. Each
> client/application who wants to use the container needs to add code
> to provide the synch. outside the container.

From my point of view (as a container maintainer) there are lots of
problems.

If the only thing you need is a "secure-release" protocol, where it's
the users' responsibility to secure before accessing and to relase
when done, that's easy enough.

But it's not what most people want, especially when they get the bit
between their teeth (and they don't have to pay for it):

* they want "multiple-reader/single writer"

* they want the individual container operations to be safe

* they want multiple iterators over the container at the same time

* they want to be able to add and delete from the container in the
  presence of multiple iterators (who knows what the semantics of that
  are supposed to be!)

and the whole enterprise just falls apart.


Consider also Queues as they were supported by the BCs before I
removed the concurrency: if you try to read from an empty queue, then

* if it's not concurrent, you get an exception

* if it is concurrent, you block until some other task adds something.

And for some reason, Sets had the same behaviour (but Bags didn't).


No, it's best if users add their own concurrency support.