undefined | Better HN

0 pointssanxiyn5y ago0 comments

Yes, but why would you want that? Using OS threads is better in most cases.

0 comments

7 comments · 4 top-level

10000truths5y ago· 3 in thread

OS threads are preemptive and their scheduling is beyond your control, which introduces potential data races. Green threads allow for cooperative scheduling, which is much harder to mess up.

Yoric5y ago

In my experience, past some level of code complexity, you get the pretty much same kind of races with cooperative scheduling as with preemptive scheduling – with the added risk that you did not expect a race with preemptive scheduling.

Still a fan of async programming, but that's a false benefit in my books :)

sanxiynOP5y ago

This is moot. Rust prevents data races.

brundolf5y ago

It doesn't prevent race conditions, which may be what the GP meant to say

vvanders5y ago

OS threads cost you stack space, among other things.

There's a reason that most OS native UI frameworks use some sort of event polling structure(WNDPROC[1], Looper/Handler[2], etc) because they're a nice structure for efficient handling of events. Tokio lets you do that across a diverse of events and get the same type of savings.

[1] https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Wind...

[2] https://developer.android.com/reference/android/os/Looper

jandrewrogers5y ago

OS threads have a high real-world cost that limits throughput, and some things are much simpler to design in an async architecture generally. Context switching is expensive on modern systems, due to both CPU cache thrashing and implied resource cost. In many server applications the CPU will spend more time context switching in massively multithreaded architectures than actually running application code. An async architecture can complete tens of millions of independent operations per second in practice; the OS would have a difficult time just context-switching at that rate even if it was doing nothing else.

Furthermore, some classes of major macro-optimizations can't be implemented effectively if you do everything with kernel threading. This is the reason most modern server software architectures tend be thread-per-core pure async with no real multithreading per se -- it is for the performance.

At a more practical engineering level, these architectures are not more complicated, just different. Some things are much simpler to design because most multithread coordination problems go away. It is nice to be able to write virtually all of your code in single-threaded style where you don't have to worry about locking and consistency, especially as concurrency increases. On the other hand, you have to learn how to design schedules because the OS will no longer be doing that (poorly) for you. It isn't free in that you have to develop expertise in things you may not know but it is often worth it.

Groxx5y ago

Most is not all. And some systems (especially embedded) do not have OS threads - they can still make use of green threads / async code.

j / k navigate · click thread line to collapse