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.