unique pointers

4.21: news.adda/dstr/unique pointer:

. the idea behind the unique pointer
is that they can be safely moved between threads
and they never require locking;
[. I first saw this idea in ms`singularity;
the msg's are instantanious because
they involve moving
only a shared heap pointer
rather than a record between process heaps .

problems with maintenance:
. after a move for a unique pointer,
the source has to be set to null?
I thought a simpler idea would be
a handle to a record (pointer, owner ID );
and then, in order to use the pointer,
you had to set the owner ID to
the process you were passing it to .
. anyone using it would first have to check for
whether they actually owned it at the moment .
once they were done with it
they would hand it to the system (ID=0)
or they could communicate it to a co.process .]

making concurrent programming safer:
. he proposes to do this by
extending the type system.

. two major challenges in multithreaded programming
are identified as:
Avoiding races -- approachable,
Preventing deadlocks -- pie in the sky.

. his main reference is:
Object Types against Races (pdf):
. Cormac Flanagan and Mart ́ Abadi .
This paper investigates an approach for
statically preventing race conditions in an oop language.
The setting of this work is a variant of
Gordon and Hankin’s concurrent object calculus.
We enrich that calculus with a form of
dependent object types
that enables us to verify that threads
invoke and update methods only after
acquiring appropriate locks.
We establish that well-typed programs
do not have race conditions.