As far as I understand, the Blazor WebAssembly runtime is single-threaded.
Can someone describe or point to a reference that explains how the garbage collector execution is interleaved with the rest of the Blazor application?
I would like to understand its concurrency details.
Does the garbage collector run on the same thread as the UI?
Is it generational?
If that is the case, will a full garbage collection stop the world
until complete or is it executed in chunks to keep the UI responsive?
Is it done on a high level (i.e. using Tasks) or is it performed at a
lower level? (perhaps invoked by the IL bytecode interpreter in a cooperative way?)
Related
I have a node process that runs tasks. When I run an intensive task, in top it can show more than 100% CPU usage (around 110%). From some research that I was doing, I figured that nodejs was single-threaded meaning it would only be running on one CPU per process.
Is it possible that the workload could take up the whole CPU so it moves some of the load to another CPU? Was unable to find a clear answer on this.
Other than specifically coding with WorkerThreads (which it doesn't sound like you are using), nodejs runs your Javascript code in only a single thread (e.g. the interpreter itself just uses one thread to run Javascript opcodes).
But, nodejs does have other threads that are used in the implementation of library functions such as file system operations and crypto operations and for the garbage collector. And, some 3rd party libraries may use native threads in their own implementation. So, it is definitely possible for nodejs to use more than just one core. It really depends upon what the code/task is doing and what library functions are being called.
Is it possible that the workload could take up the whole CPU so it moves some of the load to another CPU?
It does not move the running of your Javascript to another CPU. But as I said above, some library functions that use native code may use additional threads.
Nodejs can not have a built-in thread API like java and .net
do. If threads are added, the nature of the language itself will
change. It’s not possible to add threads as a new set of available
classes or functions.
Nodejs 10.x added worker threads as an experiment and now stable since 12.x. I have gone through the few blogs but did not understand much maybe due to lack of knowledge. How are they different than the threads.
Worker threads in Javascript are somewhat analogous to WebWorkers in the browser. They do not share direct access to any variables with the main thread or with each other and the only way they communicate with the main thread is via messaging. This messaging is synchronized through the event loop. This avoids all the classic race conditions that multiple threads have trying to access the same variables because two separate threads can't access the same variables in node.js. Each thread has its own set of variables and the only way to influence another thread's variables is to send it a message and ask it to modify its own variables. Since that message is synchronized through that thread's event queue, there's no risk of classic race conditions in accessing variables.
Java threads, on the other hand, are similar to C++ or native threads in that they share access to the same variables and the threads are freely timesliced so right in the middle of functionA running in threadA, execution could be interrupted and functionB running in threadB could run. Since both can freely access the same variables, there are all sorts of race conditions possible unless one manually uses thread synchronization tools (such as mutexes) to coordinate and protect all access to shared variables. This type of programming is often the source of very hard to find and next-to-impossible to reliably reproduce concurrency bugs. While powerful and useful for some system-level things or more real-time-ish code, it's very easy for anyone but a very senior and experienced developer to make costly concurrency mistakes. And, it's very hard to devise a test that will tell you if it's really stable under all types of load or not.
node.js attempts to avoid the classic concurrency bugs by separating the threads into their own variable space and forcing all communication between them to be synchronized via the event queue. This means that threadA/functionA is never arbitrarily interrupted and some other code in your process changes some shared variables it was accessing while it wasn't looking.
node.js also has a backstop that it can run a child_process that can be written in any language and can use native threads if needed or one can actually hook native code and real system level threads right into node.js using the add-on SDK (and it communicates with node.js Javascript through the SDK interface). And, in fact, a number of node.js built-in libraries do exactly this to surface functionality that requires that level of access to the nodejs environment. For example, the implementation of file access uses a pool of native threads to carry out file operations.
So, with all that said, there are still some types of race conditions that can occur and this has to do with access to outside resources. For example if two threads or processes are both trying to do their own thing and write to the same file, they can clearly conflict with each other and create problems.
So, using Workers in node.js still has to be aware of concurrency issues when accessing outside resources. node.js protects the local variable environment for each Worker, but can't do anything about contention among outside resources. In that regard, node.js Workers have the same issues as Java threads and the programmer has to code for that (exclusive file access, file locks, separate files for each Worker, using a database to manage the concurrency for storage, etc...).
It comes under the node js architecture. whenever a req reaches the node it is passed on to "EVENT QUE" then to "Event Loop" . Here the event-loop checks whether the request is 'blocking io or non-blocking io'. (blocking io - the operations which takes time to complete eg:fetching a data from someother place ) . Then Event-loop passes the blocking io to THREAD POOL. Thread pool is a collection of WORKER THREADS. This blocking io gets attached to one of the worker-threads and it begins to perform its operation(eg: fetching data from database) after the completion it is send back to event loop and later to Execution.
When reading Really? iCMS? Really? from this blog, one statement caught my attention:
The concurrent phases are typically long (think seconds and not milliseconds).
If CMS hogged the single hardware thread for several
seconds, the application would not execute during those
several seconds and would in
effect experience a stop-the-world pause.
Which doesn't make sense to me on preemptive operating systems. My assumption is that CMS has one or more collector threads running. Another hypothesis would be that instead of having CMS having dedicated GC threads executing the garbage collection we are talking about making application threads interleave their logic with GC logic (time-multiplexing).
Is this the case? What am I getting wrong here?
Thanks
In HotSpot JVM, the Garbage Collector (including CMS and i-CMS) uses dedicated worker threads.
CMS threads run concurrently with application threads, but they have higher priority: NearMaxPriority. On a single core machine, CMS cycle could indeed make application threads starving. The idea of CMS incremental mode was to make GC voluntarily yield CPU to the application without relying on OS scheduler.
From HotSpot GC Tuning Guide:
Normally, the CMS collector uses one or more processors during the
entire concurrent tracing phase, without voluntarily relinquishing
them. Similarly, one processor is used for the entire concurrent sweep
phase, again without relinquishing it. This overhead can be too much
of a disruption for applications with response time constraints that
might otherwise have used the processing cores, particularly when run
on systems with just one or two processors. Incremental mode solves
this problem by breaking up the concurrent phases into short bursts of
activity, which are scheduled to occur midway between minor pauses.
Note that CMS incremental mode was deprecated long ago in 2012.
I am writing a client in C# that is communicating with a Windows C++ DLL that uses boost asio asynchronous calls. I have read before that ASIO does not work too well in a managed environment. The VC++ DLL is an unmanaged project that creates an unmanaged thread for the I/O handlers. The C# code creates a background thread to handle sending messages to the C++ DLL via pinvoke. My question is - can the call to the boost::asio::async_write method be on a managed thread? Or, does it have to be on an unmanaged thread?
It will help simplify the logic and processing if I can make the call to async_write on the managed thread. But, I'm worried about what might happen when the .NET garbage collector runs and stops the threads. I don't know if ASIO will be able to handle that or not. I'm not passing any pointers to data defined in the C# code, so that should not be a problem.
The notion of a "managed thread" is a weak one, the operating system only supports one kind of thread. A thread that runs managed code isn't special, managed code gets translated to the exact same kind of machine code that a C compiler generates. The only difference is that the CLR knows about the thread and will have a reason to have a look at its stack when a garbage collection occurs. Necessary to find stack frames of managed code that may contain object references.
It will not be interested in any stack frames that belong to native code, it simply ignores them. And yes, the thread may be paused while the GC performs the search but only if it is currently executing managed code. Native code keeps running, it will only block when it returns back to a managed method if a GC is in progress. This pause isn't otherwise different from any other kind of reason a thread may pause, including losing the processor for a while when the operating system scheduler runs something else.
So using boost::asio is fine, nothing goes wrong. Just as the many other ways that a managed program can execute native code, including operating system calls. The only detail you'll want to take care of is making sure that your code gets compiled without /clr in effect. Compiling boost code to IL works fine, it just isn't very efficient.
I want to provide a way to upload plugins (assemblies) to a site by users for a scripting propose. Through mono.cecil I can analyse those assemblies and limit access only to a predefined list of functions, but I also need to limit memory usage, execution time and kill the thread if it goes to overdraft this resources.
I think I can monitor the memory usage by the profiler api, but as I know there are no tools to abort thread with guarantee. Is there any way to abort thread with guarantee? Maybe I should run code using embedding mono and control the execution of thread in native part of an application, is it possible?
You could use Thread.Abort() as long as you don't allow the plugin code to ResetAbort().
Thread level control was not practical IMHO (anyone did that in the past). Typically you should consider process level control of memory usage or application domain level.