Re: Threads?

[Per Bothner <per at bothner dot com>]

Chris Dean wrote:
> - Most application code written in Kawa will work fine in a
>   multi-threaded setup.

To the best of my knowledge.

> - Most application code will have the same restrictions that Java code
>   has.  For example, you must synchronize around critical areas in the
>   same way you would in Java.

Likewise.

> There are a few caveats:
>
> - fluid-let bindings are per thread.

Yes, but (currently, at least) inherited from parent thread.

> - If you are managing thread-specific state, you currently may need to
>   use Futures.

Or fluid-bindings.  I believe they work even without Futures.  At
least when I took a quick look at the code it looked ok.

> - Changing bindings in a top level Environment is not thread safe.

> Is that right?  If so, a couple questions: When do you have to use
> future?

At least (for now) if you want per-thread default input and output
ports.  There may be other cases I can't think of.

  What can happen if a change a binding in a top level
> Environment?  Can it corrupt that one binding or can the entire
> Environment become corrupted?

Changing an binding (i.e. once you have a Symbol) is probably safe.
Though there may be some state transitions in the type of Constraint
the Symbol uses that may not be safe.

The bigger problem is looking up or creating a binding, e.g. in
Environment.lookup(String).  This is not synchronized.  These are
called in the class initializers of compiled code.  These is a
synchronized statement in require, but my bigger concern is when a
class is initialized because of static reference.  I'd have to look
at what is going on and what to do about it.  One possibility is
to compile-in synchronization in the class initializers.

Another solution is to not use Symbols for undefined globals.  E.g.
a compiler option to require that all identifiers by bound at
compile-time.  This would be better for performance.
--
	--Per Bothner
per at bothner dot com   http://www.bothner.com/per/