GC leak?

[mike.kupfer at xemacs.org]

>>>>> "VI" == Vladimir G Ivanovic <vgivanovic at comcast.net> writes:

VI> The JVM provides (if memory serves) just one construct to manage
VI> concurrency, the monitor, which uses locks on objects to do its
VI> job. Voila! Support for multithreading, etc. in one fell swoop since
VI> everything else is implemented in class libraries.

VI> So, yes, concurrency is about data safety and liveliness, but the
VI> theory of the underlying implementation can be quite simple.

Now, are we talking about MT support that's hidden from Emacs Lisp
applications, or are we talking about exposing multithreading at the
application level?

My first full-time job was at Xerox, programming in Mesa, which had
threading primitives; synchronization was based on monitors.  Since
then, I've continued writing multithreaded code, first with Mach, then
with the Sprite and Solaris kernels.

One thing I've learned from all that is that multithreaded code is hard
to get right, at least with the commonly available primitives.  You
first need to be careful about making sure that protected data is really
protected (unless you're using a language like Mesa, where the compiler
can check for you).  And you need to structure the code carefully to
avoid deadlocks.  And you need to think harder about race conditions.

*And* even if you come up with some clean design that's easy to program
to, odds are that it won't last.  Someone will complain about how
performance isn't as good as it could be, and it's because some lock is
held when it doesn't need to be.  The fix will mostly likely involve
adding complexity to the formerly clean design, thereby making it easier
to introduce races and deadlocks in the future.

Beware.  There Be Dragons Here.

mike