At Fri, 22 Mar 2019 12:13:13 -0700 (PDT), zeRusski wrote:
> So, the `foo-struct-set!` would be atomic, but (hash-set!
> (foo-struct-field-with-table foo) key value) would not (assuming a mutable
> hash-table value there), correct?
Hash tables can be safely updated by `hash-set!` even when they a
At Fri, 22 Mar 2019 08:21:15 -0400, George Neuner wrote:
> 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 w
Thank you George for thorough explanation.
(set!) of a box, an mcons, or a *struct field* is atomic WRT threads
So, the `foo-struct-set!` would be atomic, but (hash-set!
(foo-struct-field-with-table foo) key value) would not (assuming a mutable
hash-table value there), correct?
--
You recei
I think this is a pretty good overview of the "stock" choices:
https://docs.racket-lang.org/guide/concurrency.html
On Fri, Mar 22, 2019 at 8:21 AM George Neuner wrote:
> Message passing avoids most share locking issues, so it is better to
> implement that way when possible.
I agree. Usually
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
.
In term
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
> .
>
> In terms of the evaluation model, each step in evalu
6 matches
Mail list logo
