Hacker News Reader

Comment by pron | Hacker News Reader

> It's basically the same thing reinvented with a nicer brand.

Not at all. First, don't confuse preemptive scheduling with time-slice scheduling. All "true" user mode threads are preemptive (Erlang, Go, Quasar). Not all of them employ time-sliced preemption. In fact, when we implemented Quasar on the JVM we had time sharing but then took it out because it didn't gain us anything (other than increased implementation complexity). The reason is that fibers in interactive applications follow a certain pattern that always entails frequent blocking. You are right, though, that some types of computations do not fit well with the user-mode threading model -- long, CPU intensive computations. Those are best left for kernel threads that do time sharing well. Languages that don't give you access to kernel threads might implement time sharing for their lightweight threads in user mode (e.g. Erlang).

View on HN

The parent was comparing the event model (e.g. callbacks everywhere) with a thread/process model; not comparing user-mode and kernel-mode threads. So I didn't follow your point.

Also, erlang doesn't use time slices, it counts "reductions" (essentially function calls, though I don't think it's always exactly one function call). It also penalizes processes more if they send to a mailbox that is already very large.

Erlang is considered truly pre-emptive, because (assuming you aren't writing your own functions in C or something) a function can't loop or use any operators or really do anything without potentially being pre-empted.

Go is generally considered partially pre-emptive, because it only pre-empts on a function call or during a memory allocation. You can write a simple loop that doesn't terminate, and it will never get pre-empted.

> Erlang is considered truly pre-emptive... Go is generally considered partially pre-emptive...

Well, in Quasar we started taking the "fully preemptive" route, but we saw that threads fall into two categories: those that block very often, and those that don't. Because the JVM, unlike Erlang and Go, gives you access to kernel threads, too, Quasar will simply warn you if you're using a fiber for a CPU-intensive operation that doesn't block often. Using reductions didn't work out so well because a "forcefully preempted" fiber still wants more CPU, which normally means it's doing something wrong.

Going partially pre-emptive is a reliability hit though. One errant process/thread/fiber can bring the system to a halt (or at least one hardware thread).

Erlang is designed for reliability, not CPU efficiency for CPU-intensive tasks.

Go actually does give you access to OS threads in the runtime package in the sense that you can easily reserve a thread for the current goroutine via http://golang.org/pkg/runtime/#LockOSThread and similarly can give it back up to the scheduler with runtime.UnlockOSThread()

You are wrong about Erlang. It's threads ("processes") are not preemptive and must explicitly yield for another thread to execute. Most of the time the VM handles it for you, every few hundred bytecode instructions it checks if another thread should run. But if you write a C extension, call sleep(10) then the Erlang VM will twiddle its thumbs for 10 seconds.

It's not a corner case -- it means any call to a C library needs to be carefully vetted so as to not cause an overly long computation or blocking because just a single one will totally ruin your concurrent experience. ALL VM:s using user mode threads/fibers suffer from that problem.

Real kernel threads doesn't have a lot of overhead and are almost always a much better choice.

> Most of the time the VM handles it for you

Yes, and that's the definition of preemptive. There's nothing explicit about it if the VM handles it for you. What you're saying is that it cannot preempt kernel-thread blocking code.

> Real kernel threads doesn't have a lot of overhead and are almost always a much better choice.

Well, as usual, that depends. A kernel thread task-switch is 20-50us, while a fiber task-switch is a couple nanos at most; that's a 1-2 orders of magnitude difference.

Sorry, I meant to say a couple hundred nanos.

That's just wrong. The definition of preemptive multitasking isn't that it works most of the time. A definition that lax would mean almost any cooperative threading system would be counted as "preemptive."

Also can you please find a reference that shows (Linux) kernel threads being 1-2 orders slower than user threads?

Reply on news.ycombinator.com