viega

5 ms·

31.
by viega 1y ago
Yes, I know that it was not accepted, but do not have any color on why not. It's well thought out; but I do not think the semantics are self-evident to the average C programmer who already finds the preprocessor inscrutable.
32.
by viega 1y ago
100%, that's definitely easy to do once you understand the technique.
33.
by viega 1y ago
LOL, I suffered so you didn't have to.
34.
by viega 1y ago
No. Other modern languages have strong compile-time execution capabilities, including Zig, Rust and C++. And my understanding is that C is looking to move in that direction, though as with C++, macros will not go away.
35.
by viega 1y ago
That's just: ``` #define MACRO(...) F(__VA_ARGS__); G(__VA_ARGS__) ``` The technique in the article is more often used to type check the individual parameters, or wrap a function call around them individually, etc.
36.
by viega 1y ago
And yes, GCC extensions are often going to be adopted in clang, but generally not the broader world of C and C++ compilers. Everything in my article conforms to the standard.
37.
by viega 1y ago
Author of the article here. Absolutely, the code box under the ascii art is a complete implementation, just paste that in a C file, and then use `H4X0R_VA_COUNT(...)`. Or, you could follow the link the my typed variadic arguments article (f
38.
by viega 1y ago
If you baseline against what people do when they skip builtin locks, then yes, that's spot on. Though, I was more coming from the assumption that most people are really learning about the primitives that are going to be there, and they
39.
by viega 1y ago
In terms of the relative cycle cost for instructions, the answer definitely has changed a lot over time. As CAS has become more and more important as the world has scaled out, hardware companies have been more willing to favor "perform
40.
by viega 1y ago
One thing to add here, I've enjoyed reasonably extensive support for `atomic_compare_exchange_strong()` and the `_explicit` variant for quite a long time (despite the need for the cache line lock on x86). But, last I checked (the last
41.
by viega 1y ago
Interesting, and thanks; that's not how it's supposed to look for sure. I'll ask someone to look at the whole mobile experience, definitely not my area.
42.
by viega 1y ago
Yeah, a few other people have mentioned this too; I looked and it is indeed abysmal. I'm not the person responsible for the layout, but I will make sure it gets fixed before posting anything else, even if I have to go tweak it myself.
43.
by viega 1y ago
That's very interesting history, thanks. I agree with Linux still only supporting 32-bit futexes is a bit baffling. The only reason the width matters is for the race condition check, but that's a huge reason. I'd want to have
44.
by viega 1y ago
Just because the Linux futex call is currently a Swiss Army knife with some parts that add no value (which I do say in the article) doesn't mean that it's not valuable, or important. The fact that Linux has extended it in so many
45.
by viega 1y ago
The kernel is responsible for maintaining the wait queues, and making sure that there is no race condition on the state that should preclude queueing. It does not care how you use the queue, at all. It doesn't have to be done with a lo
46.
by viega 1y ago
Yes, good comment on something I glossed over for sure (I tried to stop the mutex discussion at the process boundary, to keep from going forever).
47.
by viega 1y ago
Yeah, I don't love the mobile experience. I'll try to get that fixed soon, thanks.
48.
by viega 1y ago
Fair. That was meant as tongue in cheek-- sysv was impressive for its day, and its day lasted a long time. I appreciate that not everyone loves my style of humor, but I know when I read things with similar styles, it keeps me more engaged w
49.
by viega 1y ago
I will also say, it's likely this is the best text book on concurrency. There are some first principles where it's explanations are engaging and clear. It's just that book ignores the very real changes that are at the core
50.
by viega 1y ago
I didn't say it doesn't deal with recursive locks. I said it is so cursory that they don't even acknowledge that their guidance can't really be applied to a RW lock.
51.
by viega 1y ago
Well, you still have to enter the kernel to actually queue an OS-level thread w/ a futex. The kernel supporting being able to move stuff to userland sure doesn't guarantee better performance-- the main opportunity from that perspe
52.
by viega 1y ago
It depends on the relative cost of what you're doing of course, but in general, yes, the cost of entering the kernel can be impactful, if you are making a lot of calls into it, since a lot of work has to happen every time. There are de
53.
by viega 1y ago
No it doesn't, which is one key reason why I am a fan of `io_uring`. I brought `epoll` up because it does help with the blocking though, for most of the things that matter when it comes to async (at a cost to latency, of course).
54.
by viega 1y ago
I wrote the article; it was motivated by reading the book, which to my estimation is not well aimed for either academics or practitioners. That's a problem across a big chunk of academia right now, and I hear it not just from industry
55.
by viega 1y ago
It quite does; the kernel is not the keeper of the lock, it only needs to detect the race condition that would result in a spurious sleep. It cares not one bit about the rest of your semantics. It's true you could use it that way, bu
56.
by viega 1y ago
As the article says, the futex system call is overly complicated. But one shouldn't downplay its importance. Every major OS has had a slimmed down equivalent for about a decade, and the futex is at the core of any good modern lock. Man
57.
by viega 1y ago
Yes, it's gotten quite large, but I think with far fewer wrong turns in the API compared to the futex. Enough was available async via `epoll()` + having fd interfaces to things that I never was as worried about the arbitrary latency of
58.
by viega 1y ago
Also, I should say, in user-land you can efficiently enough save thread state, go off and do something else with that thread, then come back to it, never hitting the kernel while something blocks. That's pretty much async in a nutshell
59.
by viega 1y ago
You actually issue the `futex` system call to get yourself on the wait queue tied to the memory address. It separates out the waiting from the locking. And that can absolutely save a bunch of system calls, especially vs. polling mixed with
60.
by viega 1y ago
The computational complexity for lexing C++ is linear, but for parsing C++ it's super-linear, as will be many analyses. In practice, the lexing is in the noise for almost all compliers.

More ›