Racket threads are not cooperative multitasking. There are no explicit
yield points. The runtime system still schedules the threads
independently, but there is only ever at most one running at a time.
Racket's threads are designed to support concurrency (ie a particular
kind of non-determinism
Thank you! The set! primitive is atomic - that's good.
Futures and Places both are interesting concepts with implementations
and documentation.
But what if I want to try my own model? Let's say, for example, tying true
parallelism to objects (by using environments, a special send and threads
in
On Wed, Jun 3, 2015 at 9:18 AM, Michael Tiedtke
michael.tied...@o2online.de wrote:
Thank you! The set! primitive is atomic - that's good.
Just to be clear: when you are using futures with set!, you get the
lower-level guarantees here, which do not include atomicity, indeed
not even SC.
Futures
I'm currently implementing a new parallel objects policy (SAKE: Skip Animation
and Skedule) and I'm supposing that setting boolean values (even with an
accessor via send) is atomic with respect to its reads. I can't remember where
but the documentation (Guide or Reference) somewhere stated that
4 matches
Mail list logo
