5 ms·

You must be some sort of programming GOD, I guess. The problem is that its _hard_ to get right. For example - It's not trivial to use locks when you're workin

by devxpy 8y ago

You must be some sort of programming GOD, I guess. The problem is that its _hard_ to get right. For example - It's not trivial to use locks when you're working at an abstraction level higher than operating systems. Most people don't even realise there is a race in their application, because locks are inherently non-enforcing. Code written in locks is also really hard to read and reason by. Message passing just makes it a little more trivial to avoid the pitfalls associated with parallel programming. I also found that it lets you avoid busy waiting in certain places, which is always a performance advantage :) Can you shed some light on those "idiot-proof thread-safe datastructures"?

TickleSteve 8y ago
busy-waiting is a valid technique for some use-cases (and gives better performance in those situations) than other techniques. Please research your topic.
- devxpy 8y ago
  Yes, but isn't it more CPU intensive? (Speaking purely from experience. Don't have a fancy CS degree)
  - TickleSteve 8y ago
    It uses 100% CPU, true but when the duration of the lock is extremely small (i.e. nanoseconds->microseconds) the total CPU usage is less than arranging for an OS level context-switch. In other words, you use it when synchronising with hardware or when implementing test-and-set primitives for higher level mechanisms. Crucially, the time that the lock is held for must be very short. Given those restrictions and use cases you get a very efficient low latency locking mechanism.
twblalock 8y ago
I do concurrency in Java all the time with CompletableFuture and threadsafe data structures provided by various libraries, e.g. the Guava caches, and I rarely need to use locks or semaphores. It's a good set of abstractions that make concurrency pretty close to idiot-proof. Futures in particular make it easy to write concurrent code close to the way you would write single-threaded code, because all of the threading is handled behind the scenes.

by devxpy 8y ago

TickleSteve 8y ago

busy-waiting is a valid technique for some use-cases (and gives better performance in those situations) than other techniques. Please research your topic.

devxpy 8y ago
Yes, but isn't it more CPU intensive? (Speaking purely from experience. Don't have a fancy CS degree)
- TickleSteve 8y ago
  It uses 100% CPU, true but when the duration of the lock is extremely small (i.e. nanoseconds->microseconds) the total CPU usage is less than arranging for an OS level context-switch. In other words, you use it when synchronising with hardware or when implementing test-and-set primitives for higher level mechanisms. Crucially, the time that the lock is held for must be very short. Given those restrictions and use cases you get a very efficient low latency locking mechanism.

twblalock 8y ago

I do concurrency in Java all the time with CompletableFuture and threadsafe data structures provided by various libraries, e.g. the Guava caches, and I rarely need to use locks or semaphores. It's a good set of abstractions that make concurrency pretty close to idiot-proof. Futures in particular make it easy to write concurrent code close to the way you would write single-threaded code, because all of the threading is handled behind the scenes.