I will definitely be exploring that. If we had to transmit (a copy of) the entire HEAP, this might, in fact, not be worthwhile doing. However, I wonder if we couldn't statically determine the shared memory accesses and only buffer the effects of operations manipulating the shared heap, which we send over to the other side at the sync points. The reasoning behind this is that the compiler should be able to relate any HEAP access to an initial memory allocation. It had to do some bookkeeping to "remember" the thread where that memory allocation happened. Only if another thread accesses a piece of state relating to a memory allocation done by another thread, we had to record the effect of that memory access.
Admittedly, this is a complex feature to implement in the compiler (or not, haven't explored that really). So alternatively, we could as well have some sort of programmatic annotation, where we explicitly mark shared memory accesses. This would do away with pthread (or whatever native threading library) compatibility, but would still give us something similar. As we had to make the blocking operations non-blocking (i.e., asynchronous) anyways, this may well be acceptable. And if that works without major performance implications, one could later let the compiler do that job statically at compile-time. Not sure when I come to doing that, will initially be extending the SIMD support, which is still patchy and does not make available the full expressiveness of the Javascript SIMD object to emscripten-ed code. Soeren On 8 Apr 2014, at 9:33, Alon Zakai <[email protected]> wrote: > > > > On Wed, Apr 2, 2014 at 5:37 AM, Soeren Balko <[email protected]> wrote: > ...alright, I know this has been discussed before: Javascript doesn't have > threads with shared state and, hence, pthreads are not supported. Web workers > do offer concurrency, but rely on asynchronous message passing and can, > hence, not be used to simulate pthreads. So I thought. > > But here is a number of observations: message passing to/from workers using > postMessage are actually synchronous (to some extent) from a _sender_ > perspective. Both Firefox and Chrome behave like so: when a postMessage call > is performed, the receiving thread (i.e., some worker or the UI thread) will > _immediately_ receive the message. That is, the stack does not have to unwind > before the message is delivered to the other thread. > > How could this help to use Web workers to simulate pthreads w/ shared state? > > We could have each thread hold its own copy of HEAP and use > postMessages/onmessage to transfer the operation changing the state. In > effect, multiple threads could temporarily see different versions of some > shared state. Once an operation from another thread is received, it is > applied to the local HEAP copy. Is this necessarily incorrect? I don't think > so: unless there is some synchronization (see below) happening, two threads > cannot know what the other is doing and must not assume anything about the > effects of the other thread. So even if the other thread has already updated > a piece of shared state and this effect is not yet known locally, this is not > wrong. As long the other thread _eventually_ sees the effects of the first > thread, this should be correct. > > This is correct, and in fact is how many CPUs work. x86 tends to be coherent > all the time, but ARM and others require explicit sync points between > threads' views of memory. So your postMessages would represent such sync > points. > > But, performance sounds poor - we would need to send the entire heap in each > such message, unless we log out each write. And I think we need to log out > each write anyhow - otherwise, how do we merge changes between two threads? > We need to know which are the new changes and which the old state, so we can > keep the new changes. > > Despite my skepticism, I think this is interesting and worth exploring. If > you make a prototype it would be a good way to see exactly what the perf > impact is here, very curious about that. > > - Alon > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "emscripten-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/emscripten-discuss/IxXL55-0vKU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. Dr. Soeren Balko Founder & Director zfaas Pty. Ltd. +61-(0)4-81393191 [email protected] -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
