3 ms·

Just out of curiosity - is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex? func (*Mutex)

Just out of curiosity - is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex? func (*Mutex) Lock Lock locks m. If the lock is already in use, the calling goroutine blocks until the mutex is available. http://golang.org/pkg/sync/ http://golang.org/pkg/sync/ It seems to me this is a valid alternative to [rigidly] sticking to pure message passing.

rdtsc 12y ago
> is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex? Well aside from the deadlock or priority inversion of sorts that should work. Just like it would work in C/C++/Java etc. The real problem is when the shared data is not controlled by a mutex, but should be.
Animats 12y ago
In most languages, the language says nothing about what data is protected by the mutex. Modula and Ada did, and Java has "synchronized" objects, but C/C++/Go lack any syntax for talking about that. This typically becomes a problem as a program is modified over time, and the relationship between mutex and data is forgotten.
- masklinn 12y ago
  > In most languages, the language says nothing about what data is protected by the mutex. Or the other way around, what mutex protects a piece of data (or even that a piece of data should be protected at all), so it's easy to forget it and just manipulate a bit of data without correctly locking it. I was pleasantly surprised to discover that Rust's sync::Mutex owns the data it protects, so you can only access the data through the mutex (and the relation thus becomes obvious).
lomnakkus 12y ago
In short: We (as a field) tried them for many many (many!) years now and they have been found lacking -- in practice they're just too hard to get right for large-scale systems. EDIT: The mutexes themselves are easy enough to get right, it's the systems using mutexes that are too hard to get right.

rdtsc 12y ago

> is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex? Well aside from the deadlock or priority inversion of sorts that should work. Just like it would work in C/C++/Java etc. The real problem is when the shared data is not controlled by a mutex, but should be.

Animats 12y ago

In most languages, the language says nothing about what data is protected by the mutex. Modula and Ada did, and Java has "synchronized" objects, but C/C++/Go lack any syntax for talking about that. This typically becomes a problem as a program is modified over time, and the relationship between mutex and data is forgotten.

masklinn 12y ago
> In most languages, the language says nothing about what data is protected by the mutex. Or the other way around, what mutex protects a piece of data (or even that a piece of data should be protected at all), so it's easy to forget it and just manipulate a bit of data without correctly locking it. I was pleasantly surprised to discover that Rust's sync::Mutex owns the data it protects, so you can only access the data through the mutex (and the relation thus becomes obvious).

lomnakkus 12y ago

In short: We (as a field) tried them for many many (many!) years now and they have been found lacking -- in practice they're just too hard to get right for large-scale systems. EDIT: The mutexes themselves are easy enough to get right, it's the systems using mutexes that are too hard to get right.