> > But perhaps you meant mainly to suggest FSET as a method for avoiding shared > mutable data? There should never be open mutation, even of the closure data. > The safety of fully parallel concurrency can only be guaranteed by performing > all mutations through BECOME which relies on a CAS operation in the dispatch > threads. > > I suppose you could get around that restriction with FSET. But then so could > you with LOCKS and SEMAPHORES and all the other SMP primitives. > > Right now, as long as you abide by functional coding and BECOME as the only > mutator, we can completely dispense with LOCKS, THREADS, SEMAPHORES, > MAILBOXES. None of that is necessary at the user programmer level. You code > as though you are the sole occupant of the machine. And so long as you abide > by clean conventions, fully parallel concurrency is yours. > > The same code runs as well in a single thread, or on multiple cores and > threads. Speed of execution is the only variable.
This is a fairly narrow mode of operation, where a task can functionally produce an output that gets committed with a single atomic operation. Most often, (green or SMP) threads are used when an operation must naturally interleave computation with mutation of shared structures and I/O. -- Stelian Ionescu
