Poor performance of `lock(l) do` closures, caused by poor performance of capturing closures

General Usage Performance
,
13

Wellllllllllllllllllll this is embarrasing.

This macro already exists … in Base! … and it’s exactly as we’ve written it above! :sweat_smile::sweat_smile:

Haha sorry for all this drama. I don’t know how I missed that.
https://github.com/JuliaLang/julia/blob/6c9bc51b80a626a656aeca9758556495c1676c2b/base/lock.jl#L178-L188

Many thanks to @jameson for pointing this out.

BUT It seems like it’s still good we’re talking about this! Shouldn’t everyone always use this instead, like, all the time?

In fact it looks like almost no one uses it:
https://juliahub.com/ui/CodeSearch?q=lock&u=use&t=macro
Only CuArrays is using it right now.

Is there any reason everyone shouldn’t be using this?
Some thoughts and concerns:

  1. It’s not currently exported, so not very discoverable:
    julia> @lock ReentrantLock() 2
ERROR: LoadError: UndefVarError: @lock not defined
in expression starting at REPL[1]:1
  2. It’s not mentioned in any of the docstrings for locks, so again not very discoverable
  3. It doesn’t have its own docstring, so not very discoverable
  4. It seems like this should be preferred over the existing lock(f, lock). Can we deprecate that in favor of this?

~I’ll open~ an issue to document and export the macro at least.

Okay i’ve opened an issue here :relaxed::
https://github.com/JuliaLang/julia/issues/36441

6 Likes