4 ms·
There are no reasons to use busy waiting in Erlang. Ever.
by exo762 14y ago
There are no reasons to use busy waiting in Erlang. Ever.
- StavrosK 14y agoThere are no reasons to use busy waiting anywhere. This isn't what we're discussing, though.
- scott_s 14y agoWell, yes, there is. When implementing locks, it depends on how likely and how long contention is. If the expected cost of busy waiting is less than the expected cost of interacting with a heavier-weight scheduling system (which may mean crossing the kernel boundary), then busy waiting is better. This is, of course, for lower level codes. For example, spin locks (so-called because they spin - or, busy wait - on a status variable) are frequently used in kernel code, and I have used them in a memory allocator.
- StavrosK 14y agoSure, in that case, it makes sense. As you say, though, it's for lower-level codes.
- davidw 14y agowhile(true) would be pretty bad form in a Node program too, and doesn't actually seem to be a big problem in practice for people.
- rdtsc 14y agoIt is a magnitude easier in Node to block the whole OS process by doing anything CPU intensive. In Erlang, if not using C-bindings, there is nothing a single Erlang process can do to block the whole runtime.
- matthavener 14y agoIs it even possible to busy wait in Erlang?
- rdtsc 14y agoWell do you mean per-process or for the whole node? You'd have to go out of your way in any case. For process you could create a tail recursive loop that just calls itself. It will run for 2000 reductions then the scheduler will kick it out and so on. But it own't block other processes. To block a whole node'd have to perhaps write a native functions a (NIF) and do it there. Which is also a reason to be careful with NIFs, they can kill predictable latency under load, while initially in serial benchmarks they could show a performance improvement.