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 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.
