Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: Named (machine-wide) Mutex ... When ? #41912

Open
DevDevious opened this issue Oct 10, 2020 · 8 comments
Open

feature: Named (machine-wide) Mutex ... When ? #41912

DevDevious opened this issue Oct 10, 2020 · 8 comments

Comments

@DevDevious
Copy link

@DevDevious DevDevious commented Oct 10, 2020

As per title.

I am surprised that Go's Standard Library does not implement a named (machine-wide) Mutex. There only one project that I know off offering an implementation, however I personally believe machine wide mutexes to be to important to be missing from the Standard Library.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 11, 2020

As there is already an external package for this, why does this need to live in the standard library? https://golang.org/doc/faq#x_in_std

@DevDevious
Copy link
Author

@DevDevious DevDevious commented Oct 11, 2020

@ianlancetaylor in my personal and subjective opinion because:

a) It is quite peculiar for a programming language aimed at writing programs for servers to miss such important functionality from its STL.

b) To my knowledge there is only one external package that provides such functionality and that one looks to be in a semi-abandoned state. With 1 star and 7 forks it might as well disappear overnight at the whim of the maintainer. On the other hand Go has a much larger community, hence much more manpower at its disposal. Having a piece of functionality added to Go's STL offers a much better guarantee to the user.

@mvdan
Copy link
Member

@mvdan mvdan commented Oct 12, 2020

such important functionality

Remember that this is subjective. I think you've shown that the vast majority of Go programmers have never needed such a feature. Otherwise, a popular third party library would exist.

hence much more manpower at its disposal

You're essentially asking that the Go project write and maintain extra software. That does not come for free, and there are limited resources. There are already too many open standard library packages which require more attention than what they're currently getting; just look at the issue tracker and the backlog of patches waiting for reviews.

So, all in all, Ian's reply still stands - if you think this is important, the first step is to maintain it elsewhere and let it become popular.

@DevDevious
Copy link
Author

@DevDevious DevDevious commented Oct 12, 2020

I think you've shown that the vast majority of Go programmers have never needed such a feature.

No, I don't think I've shown that. I couldn't have. I haven't surveyed the vast majority of Go programmers so that I can talk about their particular needs.

Otherwise, a popular third party library would exist.

It is not guaranteed that a largely spread "need" automatically leads to the availability and increase in popularity of third party libs. It is easy to find at least one counter-example: Go & Generics. People have been screaming for their addition to Go since ages, however a quick search returns only 2 third party implementations, namely genny and generics; and if judged on the bases of stars and forks, none of them will be found guilty of popularity.

You're essentially asking that the Go project write and maintain extra software.

I am merely asking the Go maintainers to consider the addition of machine-wide mutexes to the STL. I personally see this not as much as adding a new feature, but rather finishing what was already started. To me the sync package feels unfinished.

@mvdan
Copy link
Member

@mvdan mvdan commented Oct 12, 2020

I'm not saying that you need a survey of all Go programmers. But you claim that this is an important functionality with little evidence.

I don't think generics can be compared here. They can't really be implemented outside of the Go project itself, unless you use heavy amounts of code generation.

It's entirely fair for you to think the sync package needs more APIs, but it's also entirely fair for the maintainers to disagree. That's why the FAQ entry exists :)

@randall77
Copy link
Contributor

@randall77 randall77 commented Oct 12, 2020

Apart from whether this is needed, or needed in the stdlib (I agree with @mvdan here), I don't really understand the semantics, and I don't understand how we might implement it. Those both argue for a prototype outside the stdlib as a first step.

As long as every process behaves well, it works. But what happens when some process doesn't release the lock? Does it go into some sort of abandoned state? How do we get back from that state?

How do we implement this? It has to interact with the OS somehow. How? Do all the OSes we support have the capabilities we need to implement this feature? Do we need to be compatible with other languages on the same platform, so people can have cross-language locks?

@DevDevious
Copy link
Author

@DevDevious DevDevious commented Oct 12, 2020

But you claim that this is an important functionality with little evidence.

@mvdn you are basically asking me to prove that

A) People need IPC in Go applications
B) People need fast IPC in Go applications (achievable only with shared memory + machine wide mutex)
C) It happens often enough to be considered important

Point C) above I can't prove nor can you disprove for that matter. While A) and B) are truisms and unfortunately I have no idea how to prove something self-evident, especially when I have no idea what your standard of proof is.

It's entirely fair for you to think the sync package needs more APIs, but it's also entirely fair for the maintainers to disagree.

Absolutely.

@randall77

Apart from whether this is needed, or needed in the stdlib (I agree with @mvdan here), I don't really understand the semantics, and I don't understand how we might implement it. Those both argue for a prototype outside the stdlib as a first step.

There is this: juju . It claims Linux, MacOS and Windows support. No idea how many platforms is Go supposed to officially support. Probably the above + BSD & Solaris according to Wikipedia.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 12, 2020

Perhaps #33974 would be an acceptable approach to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants