4 ms·

If it was a mutex contention issue, moving it to a single core wouldn't change anything -- there would be still be contention. I'm guessing it has something to

by spudlyo 16y ago

If it was a mutex contention issue, moving it to a single core wouldn't change anything -- there would be still be contention. I'm guessing it has something to do with CPU cache hits.

bnoordhuis 16y ago
No, that's not right. There is only one code path executing so there can never be another thread contending for the same lock. A lock begins as a spinlock (busy wait loop) for a few thousand iterations before degrading to a full-blown lock that puts the thread to sleep. Because there is no other thread vying for the lock, the spinlock succeeds immediately and the thread keeps on running.
- spudlyo 16y ago
  There is only one code path executing so there can never be another thread contending for the same lock. Are you sure there is only one code path executing? Don't all the threads get allocated time slices of the single CPU? I believe it's true that there is only one concurrent code path, but a thread can still acquire a lock and then come off the CPU.
  - bnoordhuis 16y ago
    Yes, you are right - and my previous comment somewhat skims over the details. Sorry for that. :) The difference in a single-core scenario is that the threads can't all become starved because a thread on another CPU holds the lock - the VM will simply cycle to the next thread and continue. In interpreted mode you don't even suffer a context switch. One edge case is where a thread acquires a lock and is then itself put to sleep because of blocking I/O or trying to obtain another lock. But that is simply a bad practice.
JoeAltmaier 16y ago
Inter-core mutex is MUCH slower than single-core. Because of the "memory boundary" problem. See, any lock depends upon a single memory location that is atomically test and set. When more than one cpu is involved, then the memory has to be plumbed down thru caches until its in memory common to all involved cpus - which is probably main memory when more than 2 cores are involved. On a single CPU its the L2 cache.

by spudlyo 16y ago

If it was a mutex contention issue, moving it to a single core wouldn't change anything -- there would be still be contention. I'm guessing it has something to do with CPU cache hits.

bnoordhuis 16y ago

No, that's not right. There is only one code path executing so there can never be another thread contending for the same lock. A lock begins as a spinlock (busy wait loop) for a few thousand iterations before degrading to a full-blown lock that puts the thread to sleep. Because there is no other thread vying for the lock, the spinlock succeeds immediately and the thread keeps on running.

spudlyo 16y ago
There is only one code path executing so there can never be another thread contending for the same lock. Are you sure there is only one code path executing? Don't all the threads get allocated time slices of the single CPU? I believe it's true that there is only one concurrent code path, but a thread can still acquire a lock and then come off the CPU.
- bnoordhuis 16y ago
  Yes, you are right - and my previous comment somewhat skims over the details. Sorry for that. :) The difference in a single-core scenario is that the threads can't all become starved because a thread on another CPU holds the lock - the VM will simply cycle to the next thread and continue. In interpreted mode you don't even suffer a context switch. One edge case is where a thread acquires a lock and is then itself put to sleep because of blocking I/O or trying to obtain another lock. But that is simply a bad practice.

JoeAltmaier 16y ago

Inter-core mutex is MUCH slower than single-core. Because of the "memory boundary" problem. See, any lock depends upon a single memory location that is atomically test and set. When more than one cpu is involved, then the memory has to be plumbed down thru caches until its in memory common to all involved cpus - which is probably main memory when more than 2 cores are involved. On a single CPU its the L2 cache.