Concurrency issues

[jo...@mentics.com]

As we move into concurrency, we're going to run into a lot of
questions and issues to deal with. For example, what are the
concurrency requirements on the global properties?

Here's another one: what happens if I start a new thread that
repeatedly calls function foo. Then in the REPL, I redefine foo.
Should that other thread start calling the new foo or stay with the
old foo? If the new foo, I think that would likely mean that every
single function call would have to use dynamic dispatch which would
cause great tears to flow from my eyes even when not cutting onions.

[Mark Tarver]

I expect that if you redefine foo before foo is called then certainly
the new foo will operate and if you redefine it after then the old
one.

Mark

[jo...@mentics.com]

Oh, but it gets even more fun :)

At least the way shenj is currently written, we could run into this:

(not (= (foo 1 2) (eval [foo 1 2])))

They might not be equal because if foo was redefined, the (foo 1 2)
will use the old and the (eval [foo 1 2]) will use the new.

And this is just one example. cd, property vector, macros, etc., are
going to have concurrency questions.

What's popping up in my mind is that we're going to need to have some
sort of context that stores the globals so threads can have their own
view, and maybe even outside of threads we create a separate context
that has its own view. I haven't thought through that.

[Mark Tarver]

Yes; indeed. The concurrency package I am proposing is designed to be
the basis of more complex and powerful concurrency models which ride
on top. The jobs thing is an example. My main concern is that the
threads package I have built on SBCL should be portable across
concurrent platforms.

Indeed global assignments do not work well with concurrency as
observed in TBoS

QUOTE
The last reason for avoiding destructive operations is concerned with
a topic outside this book, concurrency; defined as the apparent
ability of a computer to sustain multiple simultaneous computational
processes. Following the destructive model can create programs whose
output is highly unpredictable.

For example, suppose we split a computation into two parallel
processes; a process A that takes a global *counter* and destructively
subtracts 2 and a process B that takes the same global and
destructively doubles it. The final value of *counter* is inherently
unpredictable.

For example, if *counter* = 4 and process A is applied and then
process B; then *counter* is set to 2 by A and to 4 by B.  But if B
reaches *counter* before A, then *counter* is set to 8 by B and to 6
by A.  The final value is therefore 4 or 6 depending on the order in
which the processes are applied.
UNQUOTE

Mark