On 3/22/2019 7:01 AM, zeRusski wrote:
Racket documentation doesn't tell much on the subject. The only two
things I've found are *box-cas! *and this passage from Evaluation
Model that to me remains a bit cryptic.
Threads are created explicitly by functions such as thread
<file:///Applications/Racket%20v6.90.0.901/doc/reference/threads.html?q=thread%20safe#%28def._%28%28quote._~23~25kernel%29._thread%29%29>.
In terms of the evaluation model, each step in evaluation actually
consists of multiple concurrent expressions, up to one per thread,
rather than a single expression. The expressions all share the
same objects and top-level variables, so that they can communicate
through shared state, and sequential consistency is guaranteed
(i.e., the result is consistent with some global sequence imposed
on all evaluation steps across threads). Most evaluation steps
involve a single step in a single expression, but certain
synchronization primitives require multiple threads to progress
together in one step.
That passage has to do with how the Racket virtual machine handles
threads - the code generated for threads is required to include
synchronization points where the thread can be safely halted if
necessary - e.g., for a context switch, or for GC, etc. The compiler
does this automatically, so you don't need to worry about it.
Could someone illuminate how I should be thinking about mutation in
presence of multiple green threads? E.g. mutate shared mutable
hash-table, mutate mutable hash-table held in in a struct field?
Basically, I'm trying to decide when to reach for mailboxes and other
synchronization primitives. If I'm ok with "eventually" other threads
will see that value, should I think hard about mutating things?
Racket's threads are preemptively multi-tasked, so you do need to
synchronize access to shared data structures while they are being
mutated to avoid readers seeing partial updates. Also be aware that
Racket threads do not make use of multiple cores ... to leverage
multiple cores you need to use either futures or places.
Message passing avoids most share locking issues, so it is better to
implement that way when possible.
What's comparable to Clojure atoms? Would it be boxes + box-cas!?
Yes, Racket's boxes are analogous to Clojure's atoms.
At present, any update (set!) of a box, an mcons, or a struct field is
atomic WRT threads - the *current* Racket virtual machine will not
permit a thread switch while these things are happening. Going forward
things might change with the move to Racket-on-Chez, so best always to
use deliberate synchronization when you mutate shared data.
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
