std.container.BinaryHeap + refCounted = WTF???

[dsimcha]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> I think that we need a wrapper for containers that implements the shared
> methods required and manually locks things in order to use them.  Then you
> apply this wrapper to any container type, and it's now a shared container.
> There are also certain types of containers that lend themselves to shared
> access.  For example, I can see a linked list where each node contains a
> lock being a useful type.

This is a good idea to some degree, but the thing is that it forces you to use
shared even when you're going for fine-grained parallelism and want to just cowboy
it.  For fine-grained parallelism use cases, my hunch is that cowboying is going
to be the only game in town for a long time in all languages, not just D.

> > (For arrays, I'm referring to the appending issue, which is problematic
> > when I try
> > to append to an array from multiple threads, synchronizing manually.)
> I'm interested what you mean here, I tried to make sure cross-thread
> appending is possible.
> >> dcollections containers would probably all fail if you tried to use them
> >>  from multiple threads.

Ok, I stand corrected.  It seemed to work in practice, but always I just assumed
that it was a Bad Thing to do and worked for the Wrong Reasons.

> memory (a relatively abundant resource).

Apparently you've never tired working with multigigabyte datasets using a
conservative garbage collector and 32-bit address space.