Content deleted Content added
m v2.04b - Bot T20 CW#61 - Fix errors for CW project (Reference before punctuation) |
|||
Line 7:
The term Virtual threads has been used ambiguously over the years. For example Intel<ref>{{Cite web |title=Intel Technology Journal |url=https://www.intel.com/content/dam/www/public/us/en/documents/research/2007-vol11-iss-4-intel-technology-journal.pdf}}</ref> in 2007 spoke about their hyper-threading hardware as virtual threads. Virtual threads were commercialized with Google’s Chrome browser in 2008<ref>{{Cite web |title=Threading and Tasks in Chrome |url=https://chromium.googlesource.com/chromium/src/+/HEAD/docs/threading_and_tasks.md#core-concepts |access-date=2022-04-05 |website=chromium.googlesource.com}}</ref> where virtual threads may hop physical threads. Virtual threads are truly virtual, created in user-space software
*
** This is important for response performance, that the virtual thread can react to events without programmer intervention or before concluding a current task
** Preemption requires knowledge of multi-threaded programming to avoid teared writes, data race and invisible writes by other threads
*
** This allows for using 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 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
*
** This allows for many magnitudes more threads than from using OS threads
** Go 1.18 can launch 15 million virtual threads on a 2021 consumer-grade computer, ie. 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 can through system configuration offer maybe 15,000
*
** Because allocating a virtual thread is akin to allocate memory structures, they can be allocated very quickly, like 600,000 per second. This is not possible for OS threads that would crash the host long before 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
*
** Like OS threads, virtual threads share the memory across the process and can therefore freely share and access memory objects subject to synchronization
** Some single-threaded architectures, such as the V8 ECMAScript engine used by Node.js, do not readily accept data that the particular thread did not allocate, requiring special zero-copy data types to be used when sharing data between 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 sharing makes each thread appear to be continuously executing. While concurrency is easier to implement and program, it do not offer any gains in performance
| |||