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 most primitive
operations are atomic ... Is there any way to find out about the atomicity of
procedures / primitives in Racket? The standards currently do not guarantee
anything in this respect.
Some examples with the theoretical predicate atomic?:
(atomic? semaphore-try-wait?) => #t
(define my-boolean #f)
(atomic? {lambda () (set! my-boolean #t)} => #t
(atomic? {lambda () (if my-boolean 'yes 'no)} => #t
(atomic? {lambda () [when my-boolean (set! my-boolean #f)]} => #f
Parallelism in my current project is a result of nested event handling. But
when it comes to threads I found the following statements about threads in the
Guide (Parallelism):
"Other functions, such as thread, support the creation of reliably concurrent
tasks. However, threads never run truly in parallel, even if the hardware and
operating system support parallelism."
Is there any good reason for this? It sounds like cooperative multitasking ...
The Racket Foreign Interface describes another type of atomicity: "Disables and
enables context switches and delivery of break exceptions at the level of
Racket threads." One could even call this virtual atomicity.
--
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.
