Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Traps to Developers

qouteall.fun

Post reply on HN
Print view View original

41–50 of 113 posts

Re: Traps to Developers

#41

Post by judofyr »

FFFXXX wrote: post #21
charleslmunger wrote: post #17

Earlier quoted context omitted.

>A volatile write operation prevents earlier memory operations on the thread from being reordered to occur after the volatile write. A volatile read operation prevents later memory operations on the thread from being reordered to occur before the volatile read Looks like release/acquire to me? A total ordering would be sequential consistency.

I think you are quoting from https://learn.microsoft.com/en-us/dotnet/api/system.threadin... "In C#, using the volatile modifier on a field guarantees that every access to that field is a volatile memory operation" This makes it sound like you are right and the volatile keyword has the same behaviour as the Volatile class which explicitly says it has acquire-release ordering. But that seems to contradict "The volatil…

Acquire-release ordering provides ordering guarantees for all memory operations. If an acquire observes a releases, the thread is also guaranteed to see all the previous writes done by the other thread - regardless of the atomicity of those writes. (There still can't be any other data races though.)

This volatile keyword appears to only consider that specific memory location whereas the Volatile class seem to implement acquire-release.

Re: Traps to Developers

#42

Post by QuadmasterXLII »

dschuessler wrote: post #39
QuadmasterXLII wrote: post #5

CSS and C++ both have the “pick a subset and enforce that, or suffer” nature. On my to-do list: make a github action that requires manual override to merge any pull request with a css attribute not already present

I am unsure how this is supposed to work for CSS. To my knowledge, most CSS properties cannot be substituted for each other. If the subset to be enforced is "CSS properties already present", what is a developer supposed to do if their CSS property is not already present? Change the design?

Well, (like C++) new css attributes are constantly added. This means you constantly have to choose between the old way or the new way: either is fine, but “pick old or new at random on a per pull request basis” isn’t.

Re: Traps to Developers

#43

Post by Spivak »

mdaniel wrote: post #37

> A method that returns Optional may return null. projects that do this drive me bananas If I had the emotional energy, I'd open a JEP for a new @java.lang.NonNullReference and any type annotated with it would be a compiler error to assign null to it public interface Alpha {} @java.lang.NonNullReference public interface Beta {} Alpha a = null; // ok Beta b = null; // compiler error javac will tolerate this Beta b; if…

I question the wisdom of even having Optional in a language with nulls. It would raise some eyebrows if a function in Python returned an Optional type object rather than T | None. You have to do a check either way unless you're doing some cute monad-y stuff.

Re: Traps to Developers

#44

Post by judofyr »

dataflow wrote: post #19
FFFXXX wrote: post #16

The part about C# volatile accesses using release-acquire ordering seems to be wrong if I read the C# docs correctly. "There is no guarantee of a single total ordering of volatile writes as seen from all threads of execution" https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Somewhat off topic, but what is a realistic example of where you need atomics with sequential consistency? Like, what useful data structure or pattern requires it? I feel like I've seen every other ordering except that one (and consume) in real world code.

A mutex would be the most trivial example. I don't believe that is possible to implement, in the general case, with only acquire-release.

Sequential consistency mostly become relevant when you have more than two threads interacting with both reads and writes. However, if you only have single-consumer (i.e. only one thread reading) or single-producer (i.e. only one thread writing) then the acquire-release semantics ends up becoming sequential since the single-consumer/producer implicitly enforces a sequential ordering. I can potentially see some multi-producer multi-consumer queues lock-free queues needing sequential atomics.

I think it's rare to see atomics with sequential consistency in practice since you typically either choose (1) a mutex to simplify the code at the expense of locking or (2) acquire-release (or weaker) to minimize the synchronization.

Re: Traps to Developers

#45

Post by dschuessler »

QuadmasterXLII wrote: post #42
dschuessler wrote: post #39

Earlier quoted context omitted.

I am unsure how this is supposed to work for CSS. To my knowledge, most CSS properties cannot be substituted for each other. If the subset to be enforced is "CSS properties already present", what is a developer supposed to do if their CSS property is not already present? Change the design?

Well, (like C++) new css attributes are constantly added. This means you constantly have to choose between the old way or the new way: either is fine, but “pick old or new at random on a per pull request basis” isn’t.

You seem to assume that old CSS properties can be substituted for new ones. But as I said, to my knowledge this isn’t possible in most cases. Can you give an example of two CSS properties where 'either is fine, but only one should be used'?

Or do you mean something else altogether by 'CSS attributes'?

Re: Traps to Developers

#46

Post by charleslmunger »

FFFXXX wrote: post #21
charleslmunger wrote: post #17

Earlier quoted context omitted.

>A volatile write operation prevents earlier memory operations on the thread from being reordered to occur after the volatile write. A volatile read operation prevents later memory operations on the thread from being reordered to occur before the volatile read Looks like release/acquire to me? A total ordering would be sequential consistency.

I think you are quoting from https://learn.microsoft.com/en-us/dotnet/api/system.threadin... "In C#, using the volatile modifier on a field guarantees that every access to that field is a volatile memory operation" This makes it sound like you are right and the volatile keyword has the same behaviour as the Volatile class which explicitly says it has acquire-release ordering. But that seems to contradict "The volatil…

I too interpretat those docs as contradictory, and I wonder if, like how Java 5 strengthened volatile semantics, this happened at some point in C# too and the docs weren't updated? Either way the specification, which the docs say is definitive, says it's acquire/release.

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

"When a field_declaration includes a volatile modifier, the fields introduced by that declaration are volatile fields. [...] For volatile fields, such reordering optimizations are restricted:

    A read of a volatile field is called a volatile read. A volatile read has “acquire semantics”; that is, it is guaranteed to occur prior to any references to memory that occur after it in the instruction sequence.

    A write of a volatile field is called a volatile write. A volatile write has “release semantics”; that is, it is guaranteed to happen after any memory references prior to the write instruction in the instruction sequence."

Re: Traps to Developers

#47

Post by AnimalMuppet »

upghost wrote: post #38

> Unset variables. If DIR is unset, rm -rf $DIR/ becomes rm -rf /. Using set -u can make bash error when encountering unset variable. sweet mercy :O Someone call the Inquisition

Instead, say

  rm -rf $DIR
That is, skip the trailing slash. Then if $DIR is not set, it becomes an invalid command, because no file names were supplied.

Re: Traps to Developers

#48

Post by catlover76 »

Spivak wrote: post #43
mdaniel wrote: post #37

> A method that returns Optional may return null. projects that do this drive me bananas If I had the emotional energy, I'd open a JEP for a new @java.lang.NonNullReference and any type annotated with it would be a compiler error to assign null to it public interface Alpha {} @java.lang.NonNullReference public interface Beta {} Alpha a = null; // ok Beta b = null; // compiler error javac will tolerate this Beta b; if…

I question the wisdom of even having Optional in a language with nulls. It would raise some eyebrows if a function in Python returned an Optional type object rather than T | None. You have to do a check either way unless you're doing some cute monad-y stuff.

I think I get what you mean, but it's confusing ofc, because Optional[T] is the older type annotation in Python for T | None

But like, when it comes to unwrappable optional/result thingies, there are libs in Python to mimic that kind of behavior from Rust and functional languages.

Re: Traps to Developers

#49

Post by QuadmasterXLII »

dschuessler wrote: post #45
QuadmasterXLII wrote: post #42

Earlier quoted context omitted.

Well, (like C++) new css attributes are constantly added. This means you constantly have to choose between the old way or the new way: either is fine, but “pick old or new at random on a per pull request basis” isn’t.

You seem to assume that old CSS properties can be substituted for new ones. But as I said, to my knowledge this isn’t possible in most cases. Can you give an example of two CSS properties where 'either is fine, but only one should be used'? Or do you mean something else altogether by 'CSS attributes'?

The specific case that inspired this comment was a random mix of margin and gap

Re: Traps to Developers

#50

Post by singron »

Spivak wrote: post #43
mdaniel wrote: post #37

> A method that returns Optional may return null. projects that do this drive me bananas If I had the emotional energy, I'd open a JEP for a new @java.lang.NonNullReference and any type annotated with it would be a compiler error to assign null to it public interface Alpha {} @java.lang.NonNullReference public interface Beta {} Alpha a = null; // ok Beta b = null; // compiler error javac will tolerate this Beta b; if…

I question the wisdom of even having Optional in a language with nulls. It would raise some eyebrows if a function in Python returned an Optional type object rather than T | None. You have to do a check either way unless you're doing some cute monad-y stuff.

Maybe this is cute monady stuff, but there isn't an equivalent to Optional> with only null/None. You usually don't directly write that, but you might incidentally instantiate that type when composing generic code, or a container/function won't allow nulls.
Post reply on HN