23 Apr 2020
Not the same, but related. One is about structure, one is about execution.
Ruby’s thread is hand over to system thread manager. Two thread may work in same CPU or in diferent CPU core. So concurrency only provides a way to structure a solution to solve a problem that may (but not necessarily) be parallelizable.
So the tasks handle by threads aren’t being accomplished any quicker; they’re just being organized differenctly.
GIL - Global Interpreter Lock
If one of threads want to execute some Ruby code, it will have to acquire the lock. One, and only one, thread can hold the lock at any give time. While one thread holds the lock, other threads need to wait for their turn to acquire the lock. This has some very important implications for MRI. The biggest implication is that Ruby code will never run in parallel on MRI. The GIL prevents it.
If the threads count is greater than CPU core. The CPU usage will be consume by context switch.
The specific number may need to measure. Keep measure.