4 ms·

A lot of concurrency can be implemented without atomics. Maybe in fact all? I'm not super deep in the theory. But I don't think you can go far without controll

A lot of concurrency can be implemented without atomics. Maybe in fact all? I'm not super deep in the theory. But I don't think you can go far without controlling instruction reordering done by the compiler (as well as the CPU), which is what GP was talking about.

sargstuff 4y ago
Thread and/or concurrency abstraction (and/or other abstractions provided by a language) allows information/knowledge about how to deal with the abstraction (option or default) to be provided to the compile behind the scenes. aka when coding a program, when was the last time coded a stack/heap to do a function call with parameters instead of using a language provided way of calling a function with parameters? This just seems weird with C because C language was designed to map as closely to hardware instructions as possible (hence why quite a lot of things in C are 'undefined' / dependent on platform used.) Most modern languages are designed so that hardware issues are not a programmer's thing, but a compiler implementor's thing. Allows for much more sophisticated hardware without burdening the non-systems programmer.
- jstimpfle 4y ago
  Note that C is modern enough so all the thread stuff that you don't want to do yourself _can_ be done by a library, if you prefer. Why? Because the language already supports all the necessary primitives, like control over memory ordering. I don't necessarily think that more is required in a language. Why would you want in a language what can be easily provided by a library?
ncmncm 4y ago
Not all machines reorder instructions, and not all machines have more than one core. You always need control over your compiler, but that often does not suffice. With more than one core, you cannot do without one of atomics or custom assembly code sequences. And if the CPU reorders instructions all by itself, you need special instructions besides. Atomics in the language mean you get to let the compiler worry about most things. But an atomic operation may take enormously longer than you hope. An atomic increment may take a hundred times as long as an ordinary increment.
- jstimpfle 4y ago
  To clarify, I take atomic aligned reads and writes of machine-sized integers (say 32bit) for granted. I'm not aware of any machines where these simple read and write operations aren't atomic. So I don't consider those "atomics". By "atomics" I understand something like atomic exchange, compare-and-swap, atomic inc/dec. You can implement practical SRSW queues without atomics. Preventing reordering in compiler and CPU is enough. I believe you don't need atomics to achieve mutual exclusion, at least not for 2 processes (Peterson's algorithm). > You always need control over your compiler Yes, this was the other poster's point, you cannot implement threading purely as a library. Function calls like pthread_mutex_lock() must be synchronization points and the compiler must not reorder any instructions around them.

sargstuff 4y ago

Thread and/or concurrency abstraction (and/or other abstractions provided by a language) allows information/knowledge about how to deal with the abstraction (option or default) to be provided to the compile behind the scenes. aka when coding a program, when was the last time coded a stack/heap to do a function call with parameters instead of using a language provided way of calling a function with parameters? This just seems weird with C because C language was designed to map as closely to hardware instructions as possible (hence why quite a lot of things in C are 'undefined' / dependent on platform used.) Most modern languages are designed so that hardware issues are not a programmer's thing, but a compiler implementor's thing. Allows for much more sophisticated hardware without burdening the non-systems programmer.

jstimpfle 4y ago
Note that C is modern enough so all the thread stuff that you don't want to do yourself _can_ be done by a library, if you prefer. Why? Because the language already supports all the necessary primitives, like control over memory ordering. I don't necessarily think that more is required in a language. Why would you want in a language what can be easily provided by a library?

ncmncm 4y ago

Not all machines reorder instructions, and not all machines have more than one core. You always need control over your compiler, but that often does not suffice. With more than one core, you cannot do without one of atomics or custom assembly code sequences. And if the CPU reorders instructions all by itself, you need special instructions besides. Atomics in the language mean you get to let the compiler worry about most things. But an atomic operation may take enormously longer than you hope. An atomic increment may take a hundred times as long as an ordinary increment.

jstimpfle 4y ago
To clarify, I take atomic aligned reads and writes of machine-sized integers (say 32bit) for granted. I'm not aware of any machines where these simple read and write operations aren't atomic. So I don't consider those "atomics". By "atomics" I understand something like atomic exchange, compare-and-swap, atomic inc/dec. You can implement practical SRSW queues without atomics. Preventing reordering in compiler and CPU is enough. I believe you don't need atomics to achieve mutual exclusion, at least not for 2 processes (Peterson's algorithm). > You always need control over your compiler Yes, this was the other poster's point, you cannot implement threading purely as a library. Function calls like pthread_mutex_lock() must be synchronization points and the compiler must not reorder any instructions around them.