Hacker News Reader

Comment by rurban | Hacker News Reader

GIL less yes, but not lockless. The previous perl6 VM, parrot, had lockless threads, scaling linearly per native core. MoarVM even needs to lock on hash or array accesses, which is certainly not state of the art.

View on HN

How did parrot write arrays from multiple threads without a lock somewhere in there?

You deferred updates to the owner via scheduler, with high prio, and continue. parrot threads are lock free but not wait free. The NQP compiler needed to know about threaded writes and schedule the update, with a semaphore, while the other threads continue.

What MoarVM got better was everything else. The GC, the calling convention, the OO (6model), the jit. I was on my way to fix all the parrot damage done from the previous decade, because this would have enabled all architectures and proper threading for perl6, but then perl6 decided to kill it and go with Moar. And spread a lot of lies on threads.

I fail to see how using a semaphore to schedule work in another thread is "lock-free."

Because you wait but you don't lock. And the wait is not 100x of an instruction, normally it's the same time as for one single instruction. Writes are fast and atomic, because there's no lock. Only the writer needs to wait a bit, not any other thread.

Google for lock-free vs wait-free

The parrot threads didn't communicate with each other and you could wait until all of them finished. They provided a tiny subset of the functionality real threads offer but in a more efficient way.

Reply on news.ycombinator.com