... bidirectional communication with the kernel happens via shared memory. What could possibly go wrong?
It's 32 bytes. Educate yourself before commenting.
Restartable Sequences
71–80 of 82 posts
Re: Restartable Sequences
#72The name is so misleading... The first thing I see when hearing "sequence" is the "arithmetic sequence", like 1,2,3,4. Therefore "restartable sequence" is like 1,2,3,4, 1,2,3,4, 1,2,3,4... Closer to SQL's "CREATE SEQUENCE" than "restartable sequence of assembly instructions". I could not comprehend how this can help with lock free data exchange. I've done my homework now.
Re: Restartable Sequences
#73People who say 10x programmers don’t exist have never heard of Justine.
Re: Restartable Sequences
#74Was greenbean ever tested with NetBSD ftp
Something like
greenbean
ftp -vvd4o/dev/stdout http://127.0.0.1:8080
Also why doesn't redbean do TLS1.3
And rusage "wall time" output seems to be wrong
Too much emphasis on Unicode for me, it's off-putting
I like consoles that do _not_ support UTF-8. At least, it should be optional
Re: Restartable Sequences
#75If you had no idea what a restorable sequence is the takeaway is about halfway down the OP: “This is why Linux now provides rseq() which is a much more enlightened solution. With restartable sequences, you actually can get rid of both the mutex and atomics, while the OS continues to fully abstract scheduling. The way it works is you advise the kernel whenever your program enters a critical section of code that you do…
That’s clever — am I right to think it’s the intermediate solution between locks and full STM, implemented at the kernel level, and with zero abstraction cost?
Certainly not zero cost. Syscalls are heavy, that's why everyone prefers green threads.
And 2 more ops per rseq.
But rseq's are certainly cool.
Re: Restartable Sequences
#76Earlier quoted context omitted.
That doesn't really explain it though, IMO. IIUC, it's a sequence of instructions that either runs to completion atomically or doesn't. If it is interrupted by anything the kernel jumps you to the abort/retry vector you set with a guarantee that the last instruction in the sequence was not executed. (Based on my reading of the LWN article rwmj posted).
Yes, the API contract isn't "don't interrupt me during this critical section" it's "if you have to interrupt me during this critical section, go to this recovery/restart code". There is a time-slice extension feature in the works that's roughly "please let me finish this critical section before you interrupt me". But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multi…
> But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multitasking system.
I wonder why this is the case. Considering modern (personal) computers have more cores than available work (or won't starve other processes even if they hog a part of the available cores), I would not think it so horrible for an OS to offer a guarantee to some (maybe specially privileged) processes, that as long as they don't wait on a resource, they won't be interrupted.
We also have a perfectly workable model for describing such a state to the OS - priority inversion. Imagine a 'god mutex', which when acquired would boost your thread's priority to the maximum - as if the 'god process' would be waiting for said mutex and as long as your thread held it, it couldn't continue working, until your thread finished using it.
I think it would be a neat feature for certain real-time(ish) scenarios, like audio/video processing.
I think a lot of modern OS facilities are catering towards a world with much scarcer resources than our current one, for example, it would be perfectly fine for a process to assume at least a core part of its data is always in RAM and can't be swapped out.
When you get into low-level systems, like kernels, a lot of the need for special privileges comes from having to have these guarantees, which could be granted nowadays on a much more lenient basies.
Re: Restartable Sequences
#77Earlier quoted context omitted.
The author is referring to false sharing ( https://en.wikipedia.org/wiki/False_sharing ). CPU caches operate at cache line granularity (typically 64 bytes) so writes to one part of the cache line can require synchronization with writes to non-overlapping parts of the same cache line. This can dramatically reduce performance when there are a large number of cores operating on the same cache line. If you remove the 64…
Thanks for the effort but the q wasn't "what is false sharing", The Q is: is it true the CPU mutexes are actually slower than those implemented in userspace?
They very well can be. The CPU mutexes use some form of cache-coherency mechanism based on the MESI protocol - essentially each CPU keeps track of which other cores have a certain piece of memory in their cache, and if any of them modified it.
You can do better than that, for example, I remember reading an article about some game engine, which had a static scheduling of tasks on each frame, so, for example there was no overlap in time between thread A and thread B referencing the same piece of memory. The whole scheme worked the exact same every frame, it was truly free, and there was a zero percent chance of memory inconsistencies.
Re: Restartable Sequences
#78Earlier quoted context omitted.
Yes, the API contract isn't "don't interrupt me during this critical section" it's "if you have to interrupt me during this critical section, go to this recovery/restart code". There is a time-slice extension feature in the works that's roughly "please let me finish this critical section before you interrupt me". But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multi…
> But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multitasking system. I wonder why this is the case. Considering modern (personal) computers have more cores than available work (or won't starve other processes even if they hog a part of the available cores), I would not think it so horrible for an OS to offer a guarantee to some (maybe specially privileged) process…
Because poorly behaved processes can use this to lock up the machine.
Re: Restartable Sequences
#79If you had no idea what a restorable sequence is the takeaway is about halfway down the OP: “This is why Linux now provides rseq() which is a much more enlightened solution. With restartable sequences, you actually can get rid of both the mutex and atomics, while the OS continues to fully abstract scheduling. The way it works is you advise the kernel whenever your program enters a critical section of code that you do…
I think it wasn't explained in a very accessible way. If I got the gist right, this essentially brings "per-CPU" synchronization to userland. It's typical in the kernel to have per-cpu data, while per-thread data is rare and typically impractical. There is a high number of threads managed by the kernel, most of which probably belong to a userland process, most of which do not participate in any given synchronisation…
You don't have to use it for this. For example, you can use it for your own transactional memory or hazard pointer scheme.
Re: Restartable Sequences
#80Earlier quoted context omitted.
The concept of a polyglot[0] has been around for ages : the Wikipedia page mentions an 8-language one going around on Usenet in the 1990s. If it works for source code, and for scripting languages, and for things like PDF+ZIP, why wouldn't there be a pretty good chance the various executable formats are flexible enough to allow for it too? A libc which is flexible enough to select specific code paths depending on runt…
Yes, polyglot binaries are a straightforward extension of the notion of polyglot source code to binary executable files. But APE/Cosmopolitan takes this to insane levels: - a fully cross-platform libc with cross-platform support built into the output binary, integrated into clang and gcc toolchains - not just cross-platform, but also cross-architecture : output binaries work unmodified on both AMD64 and ARM64 archite…
APE is too much of a hack to be called "production-ready". It works, but there really is not much guarantee it will continue to do so.