Re: [racket-users] Parallelism / atomic?
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 useful for networking and guis etc), not
parallelism.
Threads support sequential consistency, and mutations via set! are atomic.
The support for parallelism in Racket includes places (a
message-passing mechanism with no shared memory) and futures (shared
memory).
In both cases of these cases, there is little that is atomic and the
memory model is crappier than sequential consistency as Racket
currently reflects what the OS and hardware support.
Robby
On Wed, Jun 3, 2015 at 12:36 AM, Michael Tiedtke
michael.tied...@o2online.de wrote:
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.
--
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.
Re: [racket-users] Parallelism / atomic?
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 the usual sense without any further overhead by the runtime
environment if not my own? Racket's model of threads doesn't seem to
grant me that freedom anymore but the GUI toolkit - on the other hand -
already ties threads to top level windows and their event spaces.
Racket is still a programming language where I can redefine define to be
'null but I can't use low level threads as specified in SRFI-18?
(http://srfi.schemers.org/srfi-18/srfi-18.html)
Il giorno 03/giu/2015, alle ore 13.37, Robby Findler ha scritto:
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 useful for networking and guis etc), not
parallelism.
Threads support sequential consistency, and mutations via set! are atomic.
The support for parallelism in Racket includes places (a
message-passing mechanism with no shared memory) and futures (shared
memory).
In both cases of these cases, there is little that is atomic and the
memory model is crappier than sequential consistency as Racket
currently reflects what the OS and hardware support.
Robby
On Wed, Jun 3, 2015 at 12:36 AM, Michael Tiedtke
michael.tied...@o2online.de wrote:
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.
--
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.
Re: [racket-users] Parallelism / atomic?
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 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 the usual sense without any further overhead by the runtime environment if not my own? Racket's model of threads doesn't seem to grant me that freedom anymore but the GUI toolkit - on the other hand - already ties threads to top level windows and their event spaces. You would need to build them on top of either places or futures. (Or tackle the problem of making a new runtime system for Racket, I suppose. But I guess that's not necessary in this case.) Racket is still a programming language where I can redefine define to be 'null but I can't use low level threads as specified in SRFI-18? (http://srfi.schemers.org/srfi-18/srfi-18.html) Racket is a programming language built by PL enthusiasts/researchers to do what we were interested in doing and to help us try to solve problems we wanted to solve. It isn't a finished product and if you want to build something with it or extend it, you are welcome to join in. That said, it isn't the right platform for everyone and there are many things under the sun. Best, Robby -- 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.
[racket-users] Parallelism / atomic?
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.
