.NET Threading and WebAssembly

2020-03-01

Threading, in general operating systems sense, is not something that the web has been able to use until very recently. The addition of Threads support in WebAssembly, and the activation of the threading support in Chrome opens up a whole new world of possibilities, including the use of Reactive Extensions (Rx.NET) or the Task Parallel Library (TPL). Let’s dive in, with some sample code. Threading, in general operating systems sense, is not something that the web has been able to use until very recently. The addition of Threads support in WebAssembly, and the activation of the threading support in Chrome opens up a whole new world of possibilities, including the use of Reactive Extensions (Rx.NET) or the Task Parallel Library (TPL). Let’s dive in, with some sample code. A bit of history. The only technique that was available for actual local parallelization of work in the javascript land was to use WebWorkers. It’s technically not threading in the same sense known by out-of-browsers developers, as it does not provide the ability to share memory between WebWorkers. To synchronize work, messages are passed between workers and the main loop, which looks more like processes would exchange messages via IPC. This changed recently with the ability for javascript to create shared array buffers, contiguous pieces of memory that can be both read and written from workers and the main loop. Those buffers can only be mapped to primitive types, for which access and manipulated can be synchronized via atomic operations. Atomics are also used to perform signalling between threads. Those buffers had been disabled for a while because of CPU attacks Spectre and Meltdown, but are now enabled by default in Chrome and the new Edge. Threads in Emscripten. WebAssembly Threads are supported in Emscripten via the pthreads library and are backed by WebWorkers. When threads are created, new WebWorkers are created and provided with a set of information, such as stack size, thread ID, shared memory, etc… The same WebAssembly module as the main loop one is loaded in memory in the worker, and executes the entry point requested for the thread. One interesting aspect of threading is that the creation of WebWorkers needs main loop to yield. This means that if the main loop does not yield control back to the environment, threads may never get the chance to start. That’s why Emscripten provides a way set of workers (none by default) to be created before executing any code. At this point, it is important to note that if the atomics feature is not enabled in the browser (e.g. in Firefox or Safari), the emscripten built app will fail to start. This will most probably one of the reason that the Uno.Wasm.Bootstrap project will include multi-configuration generation based on browsers capabilities. Threads in .NET for WebAssembly. .NET for WebAssembly now supports the ability to create threads, as the runtime (Mono) uses pthreads. All the existing internal .NET threading APIs have been enabled to make use of pthreads as they do for other platforms, and the System.Threading becomes available for use. With this it becomes possible to use Monitor (with lock() statements), AutoResetEvent and ManualResetEvent and other synchronization primitives are working as intended between threads. The ThreadPool is also available, along with System.Threading.Thread.ManagedThreadId, thread names and thread local storage (TLS). Trying out WebAssembly Threading with Uno.Wasm.Bootstrap. The Uno.Wasm.Bootstrap package provides the configuration to enable threading in .NET for WebAssembly by using the latest 1.1-dev package, and changing the active runtime mode. This can be done in the project file like this: <MonoWasmRuntimeConfiguration>threads-release</MonoWasmRuntimeConfigurat

Link [ https://jaylee.org/archive/2020/02/29/wasm-threads.html ]

Previous Article

.NET Threading and WebAssembly

2020-03-01

Threading, in general operating systems sense, is not something that the web has been able to use until very recently. The addition of Threads support in WebAssembly, and the activation of the threading support in Chrome opens up a whole new world of possibilities, including the use of Reactive Extensions (Rx.NET) or the Task Parallel Library (TPL). Let’s dive in, with some sample code. Threading, in general operating systems sense, is not something that the web has been able to use until very recently. The addition of Threads support in WebAssembly, and the activation of the threading support in Chrome opens up a whole new world of possibilities, including the use of Reactive Extensions (Rx.NET) or the Task Parallel Library (TPL). Let’s dive in, with some sample code. A bit of history. The only technique that was available for actual local parallelization of work in the javascript land was to use WebWorkers. It’s technically not threading in the same sense known by out-of-browsers developers, as it does not provide the ability to share memory between WebWorkers. To synchronize work, messages are passed between workers and the main loop, which looks more like processes would exchange messages via IPC. This changed recently with the ability for javascript to create shared array buffers, contiguous pieces of memory that can be both read and written from workers and the main loop. Those buffers can only be mapped to primitive types, for which access and manipulated can be synchronized via atomic operations. Atomics are also used to perform signalling between threads. Those buffers had been disabled for a while because of CPU attacks Spectre and Meltdown, but are now enabled by default in Chrome and the new Edge. Threads in Emscripten. WebAssembly Threads are supported in Emscripten via the pthreads library and are backed by WebWorkers. When threads are created, new WebWorkers are created and provided with a set of information, such as stack size, thread ID, shared memory, etc… The same WebAssembly module as the main loop one is loaded in memory in the worker, and executes the entry point requested for the thread. One interesting aspect of threading is that the creation of WebWorkers needs main loop to yield. This means that if the main loop does not yield control back to the environment, threads may never get the chance to start. That’s why Emscripten provides a way set of workers (none by default) to be created before executing any code. At this point, it is important to note that if the atomics feature is not enabled in the browser (e.g. in Firefox or Safari), the emscripten built app will fail to start. This will most probably one of the reason that the Uno.Wasm.Bootstrap project will include multi-configuration generation based on browsers capabilities. Threads in .NET for WebAssembly. .NET for WebAssembly now supports the ability to create threads, as the runtime (Mono) uses pthreads. All the existing internal .NET threading APIs have been enabled to make use of pthreads as they do for other platforms, and the System.Threading becomes available for use. With this it becomes possible to use Monitor (with lock() statements), AutoResetEvent and ManualResetEvent and other synchronization primitives are working as intended between threads. The ThreadPool is also available, along with System.Threading.Thread.ManagedThreadId, thread names and thread local storage (TLS). Trying out WebAssembly Threading with Uno.Wasm.Bootstrap. The Uno.Wasm.Bootstrap package provides the configuration to enable threading in .NET for WebAssembly by using the latest 1.1-dev package, and changing the active runtime mode. This can be done in the project file like this: <MonoWasmRuntimeConfiguration>threads-release</MonoWasmRuntimeConfigurat

Link [ https://jaylee.org/archive/2020/02/29/wasm-threads.html ]

Copyright © 2024 All rights reserved

Rss

Atom