Anyways, in this case the term "distributed" is being used to describe a mechanism which reduces memory contention when go is utilizing multiple cores on one machine.
I'd love to see more exhaustive analysis of the performance implications for this technique across a wide variety of usage scenarios.
Let's suppose we have an int, and want to add 2, we would do:
1. int i = sharedInt
2. i = i + 2
3. sharedInt = i
(that's what the compile actually does when you write sharedInt += 2).
If the runtime decides two stop the current thread on line 2 and lets the second one run all three lines, we would have a problem if I didn't use a mutex.
As for the parent discussion, usually a mutex is talking about the threading construct while a "lock service" is how you'd refer to something like etcd or zookeeper.
Don't you mean two threads accessing the same data?
Mutexes are about data protection. This usually manifests as exclusive exectution of code, but it is not the purpose.
I don't think I've ever heard of using the word mutex, namely, for synchronizing access to data over a network. Mutex kind of implies that there's the synchronization primitive and there's the data, and both can be touched separately but it's just an agreement that we touch the mutex first. However, network protocols usually just transfer updates to/from the data and then let the server do the synchronization and access pairing for each connection.
I don't think it would make sense at all to run a "mutex service" on one server and asking clients to grab that mutex before accessing another "data service" which would obviously allow any data updates by anyone without any synchronization at all.
¹ or just multiple tasks, in general. Even a single-core machine needs mutexed access to shared data because several tasks could try to concurrently use that memory location and the scheduler could switch tasks at a critical point. However, if strictly limited to single-core, and the system allows to, you can just disable interrupts while you're manipulating the data.
And yet such things exist:
http://en.m.wikipedia.org/wiki/Distributed_lock_manager
I first came across one in the context of a distributed cache which sat on top of a database. I'm not at all convinced it was a good design, but it was there!