3 ms·

Similarly, Microsoft is advising that Fibers and User-Mode Scheduling are not actually very useful anymore. https://devblogs.microsoft.com/oldnewthing/20191011

Similarly, Microsoft is advising that Fibers and User-Mode Scheduling are not actually very useful anymore. https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=102989 https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=10... Combine this with Linus's recent rant about how avoiding the kernel during thread synchronization is counter-productive leads me to think that threads + a synchronized queue built with a mutex and a condition variable is simply the simplest and most effective way to go wide.

Const-me 6y ago
> threads + a synchronized queue built with a mutex and a condition variable is simply the simplest and most effective way to go wide. Implementing an efficient synchronized queue is relatively hard. OSes already have many cross-thread queues in their user-facing APIs. On Linux I usually use mq_send / mq_receive, on Windows PostThreadMessage/GetMessage, SubmitThreadpoolWork, or PostQueuedCompletionStatus/GetQueuedCompletionStatus. On iOS and OSX there’s grand central dispatch.
- corysama 6y ago
  Anyone know where I can read up on implementing something better than something like http://www.davidespataro.it/modern-c-concurrency-synchronizing-threads-condition-variables/ http://www.davidespataro.it/modern-c-concurrency-synchronizi... without running into the kernel scheduling problems Linus ranted about? Besides the issues like how the return values of size() and empty() can be invalidated before the functions return. And, how it would be nice to have some better support for move semantics in there.
  - Const-me 6y ago
    I don't know, I'm generally happy with the way modern OSes (Windows 10, Linux 5.4) do kernel scheduling. OS queues rarely expose methods like size() or empty(). In their multi-consumer queues they normally only expose variants of enqueue() and dequeue(). Peeking or checking for empty size is only there for single consumer queues, like win32 message queue.
    - corysama 6y ago
      To be clear: My understanding of the kernel scheduling problems Linus talked about were basically that modern OSes do a very good job and people run into problems by trying to work around them. This is because the kernel will still move on doing it's job even if you don't coordinate with it. For example: when using lock-free queues you'll still get long, unpredictable pauses in your thread because it will still naturally get timesliced into a context switch eventually.
      - Const-me 6y ago
        I’m pretty sure developers of OS kernels are aware of these shenanigans. Here’s the implementation of queues in Linux: https://github.com/torvalds/linux/blob/4334f30ebf395b204c6cbeabf371a5a998d6ba7c/ipc/mqueue.c https://github.com/torvalds/linux/blob/4334f30ebf395b204c6cb... I never worked on that kernel, but on the first sight it looks like they’re using a combination of locks and lock-free stuff there.
pron 6y ago
Windows fibers and the fibers Gor Nishanov rants about as being bad in C++ have very little to do with user-mode threads in managed runtimes like Java or Go despite sharing superficial similarities. In particular, a managed runtime knows exactly how code uses the stack and understands its representation, and Java does not have pointers into the stack. This means that stacks can be moved and resized very, very cheaply. The constraints and capabilities that matter the most simply don't transfer from one language or environment to another.
- deleted 6y ago
  [deleted]
Shoop 6y ago
Do you have a link to Linus’s post? Would be much appreciated.
- corysama 6y ago
  https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 https://www.realworldtech.com/forum/?threadid=189711&curpost...

Const-me 6y ago

> threads + a synchronized queue built with a mutex and a condition variable is simply the simplest and most effective way to go wide. Implementing an efficient synchronized queue is relatively hard. OSes already have many cross-thread queues in their user-facing APIs. On Linux I usually use mq_send / mq_receive, on Windows PostThreadMessage/GetMessage, SubmitThreadpoolWork, or PostQueuedCompletionStatus/GetQueuedCompletionStatus. On iOS and OSX there’s grand central dispatch.

corysama 6y ago
Anyone know where I can read up on implementing something better than something like http://www.davidespataro.it/modern-c-concurrency-synchronizing-threads-condition-variables/ http://www.davidespataro.it/modern-c-concurrency-synchronizi... without running into the kernel scheduling problems Linus ranted about? Besides the issues like how the return values of size() and empty() can be invalidated before the functions return. And, how it would be nice to have some better support for move semantics in there.
- Const-me 6y ago
  I don't know, I'm generally happy with the way modern OSes (Windows 10, Linux 5.4) do kernel scheduling. OS queues rarely expose methods like size() or empty(). In their multi-consumer queues they normally only expose variants of enqueue() and dequeue(). Peeking or checking for empty size is only there for single consumer queues, like win32 message queue.
  - corysama 6y ago
    To be clear: My understanding of the kernel scheduling problems Linus talked about were basically that modern OSes do a very good job and people run into problems by trying to work around them. This is because the kernel will still move on doing it's job even if you don't coordinate with it. For example: when using lock-free queues you'll still get long, unpredictable pauses in your thread because it will still naturally get timesliced into a context switch eventually.
    - Const-me 6y ago
      I’m pretty sure developers of OS kernels are aware of these shenanigans. Here’s the implementation of queues in Linux: https://github.com/torvalds/linux/blob/4334f30ebf395b204c6cbeabf371a5a998d6ba7c/ipc/mqueue.c https://github.com/torvalds/linux/blob/4334f30ebf395b204c6cb... I never worked on that kernel, but on the first sight it looks like they’re using a combination of locks and lock-free stuff there.

pron 6y ago

Windows fibers and the fibers Gor Nishanov rants about as being bad in C++ have very little to do with user-mode threads in managed runtimes like Java or Go despite sharing superficial similarities. In particular, a managed runtime knows exactly how code uses the stack and understands its representation, and Java does not have pointers into the stack. This means that stacks can be moved and resized very, very cheaply. The constraints and capabilities that matter the most simply don't transfer from one language or environment to another.

deleted 6y ago
[deleted]

Shoop 6y ago

Do you have a link to Linus’s post? Would be much appreciated.

corysama 6y ago
https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 https://www.realworldtech.com/forum/?threadid=189711&curpost...