On Mon, Jul 7, 2008 at 8:04 AM, Peter William Lount <peter at smalltalk.org> wrote:
> Jason Johnson wrote:
>
> Hi,
>
> Let's drop the flawed analogy with manual memory management shall we. It
> doesn't map very well at all as an example.

No of course not.  It's quite a good analogy and just because *you*
don't see it is no reason to drop it.  As far as being "flawed", an
analogy is a *similarity* not an exact description.

>
> Unless you're claiming some advancement in process concurrency that is
> similar to garbage collection.

I made this analogy myself in [1] and various [2] others [3].  The
main point of the analogy, as mentioned in [1] is that garbage
collection allowed a level of software composability that just isn't
possible with manual memory management, and this is exactly the same
situation with fine-grained locking.

> So you're going after an Erlang model? Is that it?

That would certainly be a good evolutionary step.  It may be that the
futures/promises model used by E/Croquet/etc. is the best we currently
have.  And in either case there is no sharing between executing
entities.

> I've seen no cleaner solution presented by any of you. How is it cleaner? Be
> specific please.

Implementation papers are all over the web for all the above
technologies and more.  Here are just a few links I saw while looking
for [3]:

http://research.microsoft.com/~simonpj/papers/stm/#beautiful
(Simon-Peton-Jones, Beautiful concurrency)
http://research.microsoft.com/~simonpj/papers/stm/#composable (SPJ and
others, Composable memory transactions)
http://www.drjava.de/e-presentation/html-english/img0.html (Stefan
Reich, Escape from multithread hell)
http://Erights.org  (various regarding the E language and the futures
technology)
http://armstrongonsoftware.blogspot.com/2006/09/why-i-dont-like-shared-memory.html
 (Joe Armstrong - explanations why shared memory is bad.  His blog
contains various examples of how things are done in Erlang in the
Actor model)

http://www.eros-os.org/pipermail/e-lang/2001-July/005410.html
("Now, I agree with MarcS -- I believe that multithreading will go
down in
history next to manual memory management as one of the biggest sources of bugs
ever, and as one of the biggest preventable wastes of programmer time and
customer money ever.")

>
> All the best,
>
> Peter William Lount
> [ | peter at smalltalk dot org ] value.
>
>
>
>

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-February/114181.html
    (NOTE: futures/promises are missing from my description)
[2] http://www.cs.washington.edu/homes/djg/papers/analogy_oopsla07.pdf
        (The Transactional Memory / Garbage Collection Analogy  - Dan
Grossman)
[3] There is a paper somewhere that is literally titled something like
"similarities between shared state threading and manual memory
management".  My google-fu has utterly failed me for finding it, but I
remember very clearly that it had a name like this because I tried to
find out if it dated before my email [1] or not.