undefined | Better HN

0 pointspdimitar4y ago0 comments

Exactly because it's fundamentally hard, it must be avoided -- we the humans simply can't be trusted with it (speaking as a former C/C++ dev here).

It should also be hardware-assisted (if it's impossible to stop it at the hardware level). Stuff like atomic counters were a good first step but the state of the art there hasn't moved in a long time (we don't have atomic 512-bit update operations, do we? if we did, a lot of kernel data structures could be atomically updated; this alone would fix a lot of contention problems).

The hardware can also just work in a CRDT/OT-like manner, namely accumulate update requests for a memory location in small queues (that get flushed after 10 nanoseconds or after the mini queue fills up). This could help with a good chunk of the buggy scenarios as well.

Not saying we can make it perfect tomorrow -- of course we can't. What I am saying is that nobody [who can truly make a difference] is even trying.

It gets a bit disappointing and grim after you have been in the profession for a while, you know?

0 comments

lanstin4y ago

Switch to go and channels. You won’t have to worry about locking any more, the design of your program becomes a data flow design issue. (Speaking as a former C programmer). Hardware takes so long to change but more atomicity would be great, but 8n the meantime go runtime is fast, generally lock less to the per request application code flow, and you use all the cores evenly.

pdimitarOP4y ago

Golang's channels and goroutines are only an improvement if you are coming from JS / Python or maybe also suffered complex pthreads bugs in C/C++.

They are an improvement, absolutely, but not a big one.

swiley4y ago

OT isn't done in hardware because it would be a massive waste of transistors. It would optimize many (possibly even most) software and would just increase cost and power consumption.

pdimitarOP4y ago

And constantly reinventing broken wheels in every program isn’t a massive waste of transistors AND electricity?

I get where you’re coming from but that line of thinking got us into that mess in the first place IMO. At one point we should draw a line. Which we still don’t.

j / k navigate · click thread line to collapse

0 pointspdimitar4y ago0 comments

Exactly because it's fundamentally hard, it must be avoided -- we the humans simply can't be trusted with it (speaking as a former C/C++ dev here).

Not saying we can make it perfect tomorrow -- of course we can't. What I am saying is that nobody [who can truly make a difference] is even trying.

It gets a bit disappointing and grim after you have been in the profession for a while, you know?

0 comments

lanstin4y ago

pdimitarOP4y ago

Golang's channels and goroutines are only an improvement if you are coming from JS / Python or maybe also suffered complex pthreads bugs in C/C++.

They are an improvement, absolutely, but not a big one.

swiley4y ago

OT isn't done in hardware because it would be a massive waste of transistors. It would optimize many (possibly even most) software and would just increase cost and power consumption.

pdimitarOP4y ago

And constantly reinventing broken wheels in every program isn’t a massive waste of transistors AND electricity?

I get where you’re coming from but that line of thinking got us into that mess in the first place IMO. At one point we should draw a line. Which we still don’t.

j / k navigate · click thread line to collapse