Re-entrant locks?

[Robert Engels]

I know this topic comes up a bit and I’ve done a bit more research.

Is a contributing reason that Go does not have re-entrant locks is that Go does not have any way to get Go routine identity? It seems you cannot write a reentrant lock - at least not with the typical syntax - without specialized runtime support.

The only public way I can think of is something like

somelock.Lock(ctx)

But then you need to make every method accept a context.Context instance.

[Robert Engels]

And you have to make sure that a ctx is not incorrectly shared… ugh.

> On Feb 7, 2023, at 7:41 AM, Robert Engels <ren...@ix.netcom.com> wrote:
>
> I know this topic comes up a bit and I’ve done a bit more research.

[jake...@gmail.com]

Or maybe its because, if the language included them, then people would use them. And that is (almost?) always a bad idea. Not providing a tool that usually leads to code that is hard to maintain, and often incorrect or poorly designed seems to be in line with Go's overall vision. One of the reasons  I really like using go is that it allows mediocre programmers to write descent, reasonably solid code. And when working on a team it really matters, because, lets face it, mediocre developers abound.

Ian weighed in on reentrant locks back in the early days: https://groups.google.com/g/golang-nuts/c/4sx5pPp8gFw/m/afBJTrc7UWIJ. There are also many articles on why reentrant locks are evil. Obviously, there are those that disagree.