This is so true, I think a lot of the hype conveniently leaves out the fact that there are many low- or no-code solutions which are quite succesful in their niches (like complex form builders forgoverment tax forms, insurance etc).
Under Cargo it simply says it is capable of carrying 7,000 cars in the cargo hold. It doesn't appear to be set up for shipping container cargo. It is possible that top-loaded shipping containers don't work well with the sails/airfoil that need to be above the ship.
Probabbly don't really know what I am talking about, since only ever used async IO through boost.asio:
Isn't it a bit crazy that there are so many different ways of doing async IO on linux alone ? You would think that this is a more or less solved problem by now.
The terminology here is a bit confusing because different people have defined "async" differently, but in the strictest sense of the word, before io_uring the only other way to do async IO is POSIX AIO. See aio(7) in your man pages: http://man7.org/linux/man-pages/man7/aio.7.html
On the other hand, using select(2), poll(2), and epoll(2) is not really async IO.
The difference is really simple: for non-async IO, whenever you use read(2) or write(2) and that call returns without an errno, that operation is decidedly complete from the perspective of the user space. The buffer might not actually make it to disk (say because of caching) or the network (say because of the Nagle algorithm). But really from the user space perspective it is done.
What about "async" libraries in user space? All the bells and whistles added by these libraries in user space merely give you support for knowing when a file descriptor is ready. It doesn't make the actual reading or writing asynchronous. So with a such library, your code might appear to call read(), but the framework knows that the file descriptor isn't actually ready, suspends your greenthread/fiber/coroutine or whatever it uses and does something else. The actual read(2) call doesn't happen. The kernel doesn't know you want to read.
With io_uring, you actually deal with read or write requests sent to the kernel that are incomplete. You actually tell the kernel you want to read (by writing to a ring buffer, hence the name). The kernel knows you want to read. That's the difference.
Now don't get me wrong but I think for the majority of applications you don't need true async IO. All you really need is efficient notification of whether a file descriptor is ready. So AIO and io_uring are both niche topics that likely won't affect your app.
Really importantly, the behavior of poll/select/epoll on files is to always return "available." But a read from that file may still sleep waiting on disk — available does not mean the result is already in memory. They're only really effective primitives for networking sockets and artificial fds like signalfd().
Prior to io_uring, libraries that provide async file access in userspace (by necessity) use some kind of threadpool, with each thread processing an operation synchronously and providing an async result via self-pipe or other user-driven event.
Both competition notification and readiness notification are forms of async io. Buffering in userspace instead in kernel space is not a meaningful difference. Calling the latter not true asynch io seems incorrect to me.
It is true that readiness notification does not lend well to disk io though.
In this case I think it should be ok because !this->tasks.empty() is part of the predicate, and will be true after a new item is enqueued (and before notify is called). So if the producer is interrupted between releasing the mutex and calling notify, the consumer would not call wait.
But yeah, in general I agree with the advice.. I'm pretty sure I've made that mistake before.
It depends on if the predicate can (also) be changed without the lock being held, as otherwise the release/acquire ordering semantics are not guaranteed. So long as items are only every enqueued with the lock held, it should be ok.
"Even if the shared variable is atomic, it must be modified under the mutex in order to correctly publish the modification to the waiting thread."
That's not normative but I can't be bothered to check the c++ standard for exact wordings. Also SuSv4 doesn't have an explicit prohibition on modifying the predicate outside a critical section. But if you do, you are truly on your own.
It is because condition variables have no state, i.e. calling signal without waiters is equivalent to doing nothing and does not affect a future wait. The concern is that a thread is switched out after it checks the condition but before it calls wait, and in that moment the condition variable is signaled. The thread then calls wait and is not awoken (potentially never to be awoken). If the predicate is not altered without the mutex and the waiting thread has the mutex at the time it checks the predicate (this latter part is a must in all cases), then it is guaranteed the predicate will remain unmet at least until the thread has switched to a waiting state.
So simply using an atomic (even with a full release-acquire memory barrier) is not necessarily sufficient as that would only enforce the coherence but not prevent the scheduler from interrupting at the wrong moment.
> its usually a bug to not hold the lock before notify()
All correct non-realtime uses uses of condition variables should work fine with notify called outside of the critical section.
The only case it matters is when using strict realtime scheduling (SCHED_FIFO and SCHED_RR) and it is important that higher priority threads are woken up before lower priority ones.
The exception I guess is when paired with a condition variable, since CV waits are not guaranteed spurious and necessarily must be combined with another condition. The caveat being that the variable being tested upon wake must not be modified without the lock held (presumably to prevent reordering).
Central banks are Schrödinger institutions, both described as banks to link them to actual private banks when it suits one's argument, and also to the government agency (that they are) when it suits one's argument.
This makes me wonder:
- would there be less backlash against the econ prize had it been funded by another government agency with "bank" in its name?
- would there be less backlash if econ was like math, with no Nobel prize but a "top prize for the discipline" instead (the John Bates medal for econ, the Fields medal for math)?
I remember seeing several videos from different companies with their own version of a "pizza robot". Just look at this ad for a pizza vending machine from 2012 https://www.youtube.com/watch?v=Pyrav_9Pbsc
That vending machine pizza maker doesn't get it right either. It mixes the dough "fresh"... but that's actually not ideal. The dough needs time to absorb all the water and time to sit out and be proofed before made into pizza.
Pizza seems simple... until you want something that tastes really good...
