Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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/

It seems to me this is a valid alternative to [rigidly] sticking to pure message passing.



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.


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.


> 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).


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: