Virtual thread: Difference between revisions

Revision as of 22:45, 8 March 2024

Revision as of 23:01, 8 March 2024

Line 15:

** Preemption requires knowledge of multi-threaded programming to avoid torn writes, data races, and invisible writes by other threads

* Virtual threads can hop over the execution units of all processors and cores

** This allows forutilisation usingof all available hardware, a 10x increase on today's computers

** In the go1.18 implementation, there are virtual thread queues per execution unit. There are additional virtual threads not allocated to an execution unit and an execution unit can steal virtual threads from another execution unit<ref>{{Cite web |last=Lu |first=Genchi |date=2021-07-22 |title=Java’s Thread Model and Golang Goroutine |url=https://medium.com/@genchilu/javas-thread-model-and-golang-goroutine-f1325ca2df0c |access-date=2022-04-05 |website=Medium |language=en}}</ref>

* Virtual threads require no yield or similar interventions by the programmer

** Virtual threads appear to execute continuously until they return or stop at a synchronization lock

** Unlike coroutines, if a virtual thread is in an infinite loop, it does not block the program. Execution continues at a higher cpu load, even if there are more looping threads than available execution units

* Virtual threads can existsnumber in the tens of millions by featuring small often managed stacks

** This allows for manyseveral magnitudes more threads than from using OS threads

** Go 1.18 can launch 15 million virtual threads on a 2021 consumer-grade computer, i.e. about 350,000 per gigabyte of main memory. This is enabled by goroutines having a resizable, less than 3 KiB stack

** A consumer grade computer typically supports 3,000 OS threads an canand through system configuration can offer maybe 15,000

* Virtual threads can be allocated quickly, similar to the rate of memory allocations

** Because allocatingallocation of a virtual thread is akin to allocateallocating memory structures, they can be allocated very quickly, likeperhaps 600,000 per second. This is not possible for OS threads that would crash the host longfar beforebelow this rate

** The quicker ramp-up lessens the need for thread-pools of pre-launched threads to cater for sudden increases in traffic

** In Go, a virtual thread is allocated using a function call preceded by the keyword "go". The function call provides a closure of variable values guaranteed to be visible to the new goroutine. goroutines have no return value, so a goroutine that returns just disappears

* Virtual threads share memory map like OS threads

** Like OS threads, virtual threads share the memory across the process and can therefore freely share and access memory objects subject to synchronization

Line 33:

* Virtual threads offer parallelism like OS threads

** Parallelism means that multiple instructions are executed truly at the same time which typically leads to a magnitude of faster performance

** This is different from the simpler concurrency, in which a single execution unit executes multiple threads shared in small time increments. The sharingtime-slicing makes each thread appear to be continuously executing. While concurrency is easier to implement and program, it dodoes not offer any gains in performance

== Underlying reasons ==