5 ms·
> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads ac
by vvanders 8y ago
> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc.
It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.
- GFischer 8y agoRust evangelism strike force strikes again :) I thought of Erlang initially, and so did others in the thread.
- kazinator 8y agoActually it's very easy to avoid data-structure related deadlocks: - avoid holding two locks simultaneously: that guarantees no deadlocks. - if you have to hold several locks, always acquire them in the same order in all scenarios. The "avoid holding multiple locks" rule also harmonizes very well with "minimize the durations/sizes of critical regions". That is, hold a lock over the minimum number of machine instructions necessary. That reduces lock contention, promoting better concurrency. Of course, we don't get anything free and easy. Not holding multiple locks means that you can't lock in some consistent condition across multiple structures to do an atomic update. Any time you let go of a lock to go do something elsewhere and re-acquire the lock, the "world has changed". If the code hangs on to any previous assumptions about the state (e.g. cached info in local variables), there will be a bug.
- dreamcompiler 8y ago- Or if you have to hold several locks, grab them all atomically and if even one grab fails, release them all and try again later. - If you really need all the locks right now, steal the ones you don't own from another thread, and make sure all threads can deal with lock theft. It's not always easy to sort out the best way to deal with deadlocks. Each approach has significant tradeoffs.
- kazinator 8y agoMultiple locks are not always in the same scope. Method Foo::Update acquires a lock, then without releasing the lock calls into another class/object where Bar::Commit also acquires its own lock.
- dreamcompiler 8y agoYep. That's certainly one of the tradeoffs.
- pkaye 8y agoHow would you do this in Go? If not Go, what language has the capability?
- gatestone 8y ago"...shared values are passed around on channels and, in fact, never actively shared by separate threads of execution. Only one goroutine has access to the value at any given time. Data races cannot occur, by design." [...if you stick to this style of programming...]
- LukeShu 8y ago"avoid holding two locks simultaneously" only guarantees no deadlocks if locks are your only form of inter-thread-blocking. If you have synchronization points or channels/pipes or anything else, that needs to be expanded to include "avoid using a channel while you hold a lock" and similar for every blocking primitive.
- kazinator 8y agoThat's right; avoid doing anything that could block while holding a lock: acquiring another lock, waiting on a semaphore, and so on. Note how condition variables have an aspect of this built-in: the wait operation gives up the mutex.
- deleted 8y ago[deleted]
- rubiquity 8y agoHah! Good one. To anyone else not in on the joke, parent is referring to the language that is often discussed on HN and known for having a sometimes overly enthusiastic community, Pony: https://www.ponylang.io/ https://www.ponylang.io/
- eatbitseveryday 8y agoHah! You must be in on another joke, because OP was referring to Rust ;) > Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. www.rust-lang.org edit: /s
- nemothekid 8y agoWooosh Edit: I made this post, but I thought afterwards, what if you were you being dense on purpose, and I didn't get the joke?
- cube2222 8y agoI think this thread is a nice reminder that it's really helpful to use /s when you're using sarcasm in written form.
- deleted 8y ago[deleted]
- cpburns2009 8y agoIsn't Pony the language where x / 0 == 0?
- spooneybarger 8y agoYes but you can also have it be an error by doing x/?0 using the latest code on master.
- markdoubleyou 8y agoHah! Good one. Parent is clearly referring to Ada and the oft-quoted chapter 9 of NASA's Ada Style Guide (c. 1987). https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19870013758.pdf https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/198700... The discussion of pitfalls surrounding Ada's task facility is eerily familiar to what you're reading in this thread 31 years later.
- lurker_level_53 8y agoIs this a RUST reference?
- pknopf 8y agoYes
- deleted 8y ago[deleted]
- reacharavindh 8y agoI thought this was one of the "not strong" points of Rust? It had Tokyo, futures, async/await but I vaguely remember many libraries waiting for the async story to settle down? Is there a one standard way to do async now in Rust stable?
- steveklabnik 8y agoYou can use tokio with stable Rust. Async/await is in nightly, but won’t be stable until early next year. As part of that work, some of the APIs are changing, but there is/will be a compatibility layer to make upgrading from the stuff today to tomorrow’s stuff easier. That said, to address the question directly, rust-the-language provides a stronger guarantee than Go: rust code is free of data races at compile time. However, the APIs are much harder. Async/await will make them much easier, but still not as easy as “everything is always async.” The tradeoff is speed and safety; rust will be faster and have more guarantees, but be slightly harder to use (though some people do think the explicitness of async/await is easier, but that’s personal opinion).
- reacharavindh 8y agoThanks for the patient and detailed response Steve. I don't have a particular need for Async at the moment, and commented impulsively, but ended up learning more about current state of affairs from your response :-)
- 8y ago
- seanmcdirmid 8y agoJefferson’s Timewarp did that with “virtual time” using optimistic rather than pessimistic concurrency constructs so popular today outside of transactions.
- sitkack 8y agoHave they moved on from Starship?
- seanmcdirmid 8y agoNo connection with the band.
- flavio81 8y ago>It's almost as if we need a language that has a focus on data races, concurrency and fearless threading. How Exciting!! How Exciting!!
- tick_tock_tick 8y agoWhile I really do like Erlang I think everyone should take a look at what Elixir is doing on top of the Erlang VM. https://elixir-lang.org/ https://elixir-lang.org/
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]