5 ms·

I don't think you can conflate intent with real world application. Certainly they didn't intend for Javascript to take over the server-side world when they buil

I don't think you can conflate intent with real world application. Certainly they didn't intend for Javascript to take over the server-side world when they built the language. I don't think you can compare a GC memory model with heap/stack. There's a sliding scale of tradeoffs that you get from a fixed stack -> heap -> GC. There's also a set of hardware out there that doesn't have a unified memory model. There's millions of these types of devices out there in your set-top box, game console and many other places. If you don't have direct control over memory you'll never be able to work with them and will always need a C/C++/Rust wrapper around the low level bits. Lastly, I'd never want to use volatile for threading[1]. There's no memory barrier semantics, instruction ordering semantics(aside from with other volatile reads). If you need thread synchronization you should to use the platform specific atomics otherwise you're in for a world of pain(and god help you if you're going from x86-win32 -> ARM, there's an implicit memory barrier in x86-win32 that most people don't know about). [1] Note that volatile variables are not suitable for communication between threads; they do not offer atomicity, synchronization, or memory ordering. A read from a volatile variable that is modified by another thread without synchronization or concurrent modification from two unsynchronized threads is undefined behavior due to a data race. - http://en.cppreference.com/w/c/language/volatile http://en.cppreference.com/w/c/language/volatile

wahern 10y ago
volatile doesn't offer atomicity, but sig_atomic_t does. You can use sig_atomic_t between threads, but in most cases you need the volatile qualifier as a kind of memory barrier. The guarantees that "volatile sig_atomic_t" provide are very weak and not something you'd normally depend on (especially when you have access to POSIX, C11, or other native atomics), but can be useful on occasion. I've used it a few times when a library needs to initialize some [very simple] global state, but where I didn't want to require the application to always link in libpthread. Even on Linux that can be an issue for dlopen'd modules. glibc has bugs when late binding libpthread, and some BSDs don't even pretend it works (it just fails loading outright).

wahern 10y ago

volatile doesn't offer atomicity, but sig_atomic_t does. You can use sig_atomic_t between threads, but in most cases you need the volatile qualifier as a kind of memory barrier. The guarantees that "volatile sig_atomic_t" provide are very weak and not something you'd normally depend on (especially when you have access to POSIX, C11, or other native atomics), but can be useful on occasion. I've used it a few times when a library needs to initialize some [very simple] global state, but where I didn't want to require the application to always link in libpthread. Even on Linux that can be an issue for dlopen'd modules. glibc has bugs when late binding libpthread, and some BSDs don't even pretend it works (it just fails loading outright).