Re: Threads

[Jonathan Bachrach <jrb@xxxxxxxxxx>]

"Chris Double" <chris.double@double.co.nz> writes:

> Is there any likelihood of Goo being able to have native threading
> sometime in the future? 

we have discussed the possibility.  i think the general thought is to
not support native threads but to instead support threads built out of
upward continuations (i.e., cooperative threads).  full parallelism
would be built instead out of more insular processes.  the problem of
making user programs thread safe and the overhead of system thread
safety are thought to be too high a price to pay for parallelism.
james knight has written a couple proposals in:

  www.googoogaga.org/wiki/index.php/ContinuationIdeas
  www.googoogaga.org/wiki/index.php/ThreadIdeas

any of your thoughts on these proposals would be appreciated.  

> What would be involved in making Goo threadsafe?
>
> I see a global 'stack' variable used and functions push and pop items
> from the stack. I'm guessing this won't work as is because multiple
> methods being called at the same time are going to confuse that stack.
> Any other areas that are not threadsafe or reentrant that would need to
> be?

there are four areas that would have to be addressed in order to make
goo threadsafe: 1) multi dispatch updates 2) runtime support including
the stack that you mention 3) collection classes and 4) the compiler.

the dispatch cache reorders elements based on frequency in a thread
unsafe manner.  in fun-o dylan, we lock the cache whenever we modify
it.  in goo, we could disable the reordering code and go through the
rest of the code to ensure thread safety.  we could also install locks
on updates.  this is all pretty straight-forward.

the lower level runtime would have to be examined for thread safety.
you've uncovered the goo stack as an obvious problem.  there might be
other problems as well.  i don't expect this to be a big deal.

it might be necessary to prevent out of language errors in the runtime
when two threads accessed the same, say, vector.  we did this in fun-o
dylan.  table code would need to be examined as well, etc.  the
fun-o strategies could probably be reused for goo.

finally, the compiler itself is not thread safe.  we have started to
put in place a transaction mechanism which might be a plausible
strategy.  clearly, dynamic compilation in a multithreaded system
would itself have to be thread safe.  perhaps there are simplifying
restrictions that would reduce the complexity of this.  this is by far
the most complicated part of making goo thread-safe.

now we could pretty easily at least support 1 and 2 above.  the system
would then "work" assuming users didn't use vec/tab's and the compiler
in some thread unsafe manner.

> For the .NET port I've can spawn multiple threads and I've got the
> functionality to run tests but they blow Goo away because of the
> problems mentioned above of course:
> 
>   (dotnet-start-thread (fun ()
>   (system-windows-forms-messagebox-show-string "Hello World!")))
> 
> This starts a thread and displays a hello world message box on another
> thread. But Goo dies at random points (as I expected, I didn't think it
> would be magically thread aware).
> 
> Chris.
> -- 
>   Chris Double
>   chris.double@double.co.nz