proposal: spec: Detecting when nested mutex locks/unlocks are attempted through function calls. #69983
Closed
1 of 4 tasks
Labels
LanguageChange
Suggested changes to the Go language
LanguageChangeReview
Discussed by language change review committee
Proposal
Milestone
Go Programming Experience
Intermediate
Other Languages Experience
JS, Python, C
Related Idea
Has this idea, or one like it, been proposed before?
I don't think so. I've surfed well enough to find this kinda discussion but didn't find any.
Does this affect error handling?
Yes. This feature request is about raising an error while trying to call a function that implements a mutex lock which also calls another function that implements a mutex lock.
Is this about generics?
No
Proposal
Change: Compiler should check for the function calls that implement lock within a function that also implements a lock and give an error with the location at which the "nested" call is present. This is more of a new feature than a change (I might be wrong tho.
Example:
chirpy is a guided project from boot.dev where I was locking mutex in a function that calls an internal package function that waits for the data to be unlocked and I couldn't notice it because I didn't see any compiler errors regarding this. I'll put a conversation below for clear context.
dbPath.Mu.Lock()
defer dbPath.Mu.Unlock()
Purpose: Although a lack in skill is apparent, a simple compiler error would make it easier for new learners for the language especially with features like mutexes and interfaces which are not very common in popular languages (the features maybe present but the familiarity is low). This will save a lot of time while working with the language and mutexes specifically.
Language Spec Changes
The language spec is not affected I believe.
Informal Change
This happened two months ago but now I've got the idea to propose a feature request.
I was trying to learn web servers and in one of the projects I was doing, I used mutex to prevent data mutation. But the function that implements this also calls another internal package function which also uses mutex to lock access to the data.
It took me two weeks to understand the issue after discussing it with other gophers on a server.
It looks like this:
Is this change backward compatible?
I'm not sure about that. I've gotten into Go an year ago.
Orthogonality: How does this change interact or overlap with existing features?
I don't think so.
Would this change make Go easier or harder to learn, and why?
It'll make Go easier to learn if the compiler can detect when the programmer is trying to use nested mutexes unintentionally. It's similar to segmentation faults in C making sense.
Although not as common as segfaults, it's still very much likely given how often we use internal packages.
Cost Description
I'm not sure. I'm just making sure that someone who has a better knowledge about this will take care of it for good.
I'm not good enough to estimate things like these. I'm still a student.
Changes to Go ToolChain
I don't think any packages have done this yet. So it won't affect the tool chain.
Performance Costs
Not sure about that.
Prototype
The simplest solution that comes to my mind is that when we're compiling the code, a function that uses mutex to lock will be traced and checked if it's calling any other function that does the same, especially if it's from an internal package.
If lock is being called while it's called once, then the compiler should give an error with the location at which the call to lock is there. Current Go compiler haven't detected it, it compiled and the functions kept waiting for the data to be unlocked.
The text was updated successfully, but these errors were encountered: