Hacker Newsnew | past | comments | ask | show | jobs | submit | sethev's commentslogin

I wonder if it’s just the colorful metaphors and an opportunity to bring out examples of surprising behavior. Plus it’s a topic that can always stir up debates.

Yes, there is a data race there. The value of a volatile can be changed by something outside the current thread. That’s what volatile means and why it exists.

Edit: thread=thread of execution. I’m not making a point about thread safety within a program.


Not from the standard’s point of view. The traditional (in some circles) use of volatile for atomic variables was not sanctioned by the C11/C++11 thread model; if you want an atomic, write atomic, not volatile, or be aware of your dependency on a compiler (like MSVC) that explicitly amends the language definition so as to allow cross-thread access to volatile variables.

Thread was a poor choice of word. Outside the control of the program is a better way to put it. Like memory mapped io.

It's almost universally better to use inline assembly via a macro to read/write mmio rather than use volatile.

Can also represent a register that has an effect reading it. Reading a memory mapped register can have side effects. Like memory mapped io on a UART will fetch the next byte to be read.

Was going to say the same thing until I saw this comment. volatile is defined the way I'd expect, plus it's a strange code example.

Not sure why you're being downvoted. That's completely right. The example is silly. The code is obviously bad, doesn't matter if it's UB or not.

I'm also not convinced (yet) that the example really is UB: I agree reading a volatile is "a side effect" in some sense, and GP cited a paragraph that says just that. But GP doesn't clearly quote that it's a side effect on the object (or how a side effect on an object is defined). Reading an object doesn't mutate it after all.

But whatever language lawyer things, the code is obviously broken, with an obvious fix, so I'm not so interested in what its semantics should be. Here is the fix:

    volatile int x;
    // ...
    int val = x;  // volatile read
    printf("%x %d\n", val, val);

The problem is that the function call as a whole is UB. Having the original example compile to the equivalent of

  volatile int x;
  int a = x;
  int b = x;
  printf("%x %d\n", a, b);
is equally valid as

  volatile int x;
  int a = x;
  int b = x;
  printf("%x %d\n", b, a);
, and neither needs to have the same output as your proposed fix.

C could've specified something like "arguments are evaluated left-to-right" or "if two arguments have the same expression, the expression is [only evaluated once]/[always evaluated twice]". But it didn't, so the developer is left gingerly navigating a minefield every time they use volatile.


Not only is "arguments are evaluated left-to-right" less easy to formalize than you think, it would also make all C code run slower, because the compiler would no longer be able to interleave computations for more efficient pipelining. The same goes for "expression is [only evaluated once]/[always evaluated twice]".

Of course the developer is navigating a minefield every time they use volatile, that's why it's called "volatile" - an English word otherwise only commonly used in chemistry, where it means "stuff that wants to go boom".


Your argument makes no sense since the developer is expected to perform manual sequencing. Correctly written UB free code cannot be interleaved either.

All you've achieved is that the standard C function call syntax can no longer be used as is.


the compiler can still interleave anything it shows is side-effect free; it’s hard to show that something would benefit from being reordered without analyzing it well enough to determine what side effects it has

I understand, that's why I said the code is obviously broken. The problem is not about order of evaluation. It's not about an UB arising from unsequenced volatile reads or whatever.

The problem is simply that the there are two volatile reads where only one was intended. It doesn't matter if there is UB or not. The code doesn't express the intention either way. All you need to know to understand that is that volatile might be modified concurrently (a little bit similar but not the same semantics as atomics).


The Hard Problem strikes me as a "why" question and humans have a poor track record of ever answering a "why" for a foundational question (at least in a way that we can demonstrate to others). Our most successful explanations build up from simpler things to explain more complex things. But at some point, the explanation bottoms out on things we can't further explain - like the fields in quantum theory. There's currently no further thing below those that explain "why a field theory?"

If we solved the Easy Problems of consciousness, i think we would find ourselves in a similar position where most people would simply accept that we had an explanation and move on but some people with a more philosophical bent would continue to search for underlying explanations.


This seems sketchy. O_DIRECT skips the operating system's page cache, it does not guarantee that the SSD driver sent the data to the SSD or issued a flush to the drive itself. The data could still be in the driver's memory or the in non-durable memory in the drive itself when this engine says "ok, we're good".

EDIT: sketchy from an answering "what exactly are the guarantees?" perspective


The model here is that the storage device is directly reading and writing the userspace buffer via DMA. It is one of the reasons use of O_DIRECT creates additional constraints on buffer alignment and size.

Some storage devices guarantee durability of non-persisted writes, which is explicitly part of their model. Consequently, the entire durable write path is the storage device completing a DMA read of their buffer.

The underlying assumptions will not hold true for every environment. However, it will hold true for many and you can check most (all?) of them at runtime.


Right - I mean, what you're describing makes sense, but it doesn't sound like what they're describing. Their benchmarks are running on an EC2 instance and the post's author is here saying that they run on virtualized hardware. Plus they run on top of a file system. None of that screams "direct DMA from our buffers" to me.

I'm not saying it's impossible, but typically people who want to lean on hardware guarantees for extra performance control more of the stack.


It's fascinating to read the perspective of someone seeing X-files as a show from before their time. The clunky phones in the show, for example, were actually advanced technology that most of us had never seen in real life. The closest thing I'd seen was the IBM technician Brick that an uncle had.

> I want to twiddle the dials on a car radio

That's one thing I miss. As a kid in the early 90s, I used to collect car radios whenever someone was replacing theirs (which seemed to happen a lot more back then) - they were fun to take apart because so much of it was mechanical. Even the buttons to remember a station were mechanical and worked by using latches and levers.


Not sure that disproves the point :) Most people have never been anywhere close to competing with the top 6 athletes at a high school with ~2k students.


There are thousands of these high schools all across the USA. The top high schoolers in California so far this year are doing 1600m in 4m7s.

https://www.athletic.net/TrackAndField/rankings/list/168546/...


OK, so let's do the math. There's about 25k high schools in the USA. Let's suppose they all have a track team, and let's assume that they all have 5 team members who can break 04:30 for 1600m. Sure, at some schools that's too few, but at others it is too many.

That gives us 125k high schoolers in the USA who can break 04:30 for 1600m. There are about 18M high school students. So of just the high school population alone, about 0.7% of them can do this.

Assuming there are the 4x as many adults that can do this as there are high school students, that gives us slightly less than 0.2% of the total US population capable of this.

I rest my case.


We just have different ideas of what constitutes "mere mortals." 1 in 150 high school students or even 1 in 500 from the general population doesn't sound super human to me at all. Talented, yes but not god like.


What do you want most to mean here?


More power to them for re-visiting this, but agree with you:

> The old model assumed one person, one branch, one terminal, one linear flow.

That sounds exactly like the pre-git model that git solved..


It's kind of an aside in the post, but connecting LLMs and Searle's Chinese Room argument is a brilliant observation. Although there are people who believe LLMs are really thinking, it's mostly confirming that the Turing test wasn't the right way to test this.


Is it? The observation seems patently obvious if one has even the most superficial understanding of how LLMs work? Why is this not common knowledge?


Understanding LLMs require a few pieces of knowledge that are not very common in the industry, not only ML stuff, but I think that having worked in the past with NLP helps a lot.


I fucked around with dissociate press 30 years ago just to see what would happen if you fed it a combination of random chapters from Alice in Wonderland and the book of Revelations. This hardly represents insider knowledge.


I don't doubt that number, but it's always a bit baffling to look at the median income in expensive cities. New York city's median household income is $87k, which means that the majority of households are well below the income level it takes to live there.

That stresses me out just to think about it.


This baffles me too. I don’t understand how “normal” people let alone lower income people live in places like SF/SV, NYC, etc. The math doesn’t math. Yet these cities have these people and could not function without them.


> The math doesn’t math.

It maths fine, it's just that the assumptions being input are wrong.


People making $80-90K can live a similar lifestyle to the people making $125K+, they just aren't saving any money. I know people that do this, live their whole life with less than $5k in the bank.


Oops I read this wrong.


Majority is correct if you go by the $125k figure (which is skewed by public listing data, I’m sure)


Huh? 87k is the median, not mean, so majority would be perfectly accurate....?


Even 87k is a huge number, is it due to some selection bias?


Oops I read this wrong.


and 87k is quite a bit below 125k.


I worked at a company once that posted h-1b jobs on a piece of paper on a board next to a restroom at the office. That was technically a publicly accessible area (if you had a guest pass).


That is an LCA requirement. The company did well to publish this at a place where employees frequent.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: