-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
RFC: Add Lockable{T, L<:AbstractLock}
struct
#34400
Conversation
Locked{L <: AbstractLock, T}
structLocked{L <: AbstractLock, T}
struct
Maybe change the name to Lockable? |
Done! |
I have added docstrings, compat annotations, tests, and a |
Locked{L <: AbstractLock, T}
structLockable{T, L<:AbstractLock}
struct
Bump. What did triage think of this PR? |
The more I think about this, the more I think this doesn't need to be in Base. I think it is a useful design pattern, but it is easy to put this in a package instead of Base or a stdlib. |
I've come across the need several times lately for something like this; does it live in a package somewhere? |
Not that I'm aware of. Want to take the code and submit it somewhere? If there is some kind of "threading utilities" package, it could go there. |
I mean, for my use case, I realized I only needed: struct Lockable{T}
x::T
lock::ReentrantLock
end
Lockable(x::T) where {T} = Lockable{T}(x, ReentrantLock())
Base.lock(x::Lockable) = lock(x.lock)
Base.unlock(x::Lockable) = unlock(x.lock) So I just put it in my package directly. But yeah, sounds like a good fit for a thread utils package. |
Well, I was planning on registering this new package soon anyway, so now it includes |
Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
I am not sure about a `lock(f, ::Lockable)` method: it is nice because it unpacks the value for you, but it is weird because it unpacks the value for you. For a `Lockable`, `f` must accept one argument, whereas for a `Lock`, `f` must be 0-arg. A `Lockable` is not `<:AbstractLock` here, so maybe this is allowed, but if we deleted this `lock` method, we could inherit from `AbstractLock` and just use the generic one (requiring folks to unpack the value within the locked region themselves, as is the case for `@lock`). I think it is preferred these days to use `@lock` anyway, so having the `lock(f, ::Lockable)` method may be of limited value anyway. I searched Base and came up with two places that could currently use this internally, `TEMP_CLEANUP` and `env_dict`. We didn't add them both as usages yet, to avoid external breakage from delaying this PR. Similarly, this is not exported yet, to avoid breakage with older releases of ConcurrentUtilities.jl. redo of #34400 First commit copied from https://github.com/JuliaServices/ConcurrentUtilities.jl/blob/main/src/lockable.jl, Closes #52897 Co-authored-by: Jacob Quinn <quinn.jacobd@gmail.com> Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
I find myself using this pattern a lot, so I'm curious if it would be worth adding to
Base
.The basic idea is that there is some object that should only ever be accessed when its corresponding lock is held, so it makes sense to package the object and its lock together into a single object.
Here is the code that this PR adds to
base/lock.jl
:Example usage: