Comments (2)
No; this would be introducing behavior into the AsyncLock
class that it shouldn't have.
AsyncLock
is a coordination primitives, and it is specifically for restricting access to one block of code at a time. This is all it should do.
Adding a Taken
property would invite misuse; as you noted, there is an unavoidable race condition inherent in the property even existing.
There's also a more insidious race condition even with a TryLockAsync
: the question of "what does 'already running' mean?" Presumably, your code under lock is doing something important, but the lock is still held for some amount of time after the important work is done.
using (await asyncLock.LockAsync())
{
DoImportantWork();
// Lock is still held here, after work is done.
}
As such, most of the time when there's a "skip this if it's already in progress" requirement, the requirement itself is incorrect. It can happen - it's just extremely rare. Usually, some kind of throttling (with at least one "waiting" to get in) is a more reliable solution.
I did consider adding both a TryLockAsync
and Taken
members, but have decided not to. AsyncLock
as it currently stands does one thing extremely well; there are lots of other solutions if you need something else (in this case, Rx and/or async-compatible producer/consumer queues).
If you really do need the semantics you describe, then I recommend that you continue doing what your are probably doing now: keeping a separate boolean variable meaning "there's some other code already in this lock and I should skip processing even though there's a small chance that the processing may already be complete so this signal is lost". That way the AsyncLock
does what it does well (mutual exclusion), and something else (the boolean) handles the unusual semantics.
from asyncex.
Thanks for your extensive feedback and you are right in everything you said - just haven't thought of everything yet. Especially using some kind of "throtteling" - I just started using Rx someplace else in my application, but I didn't think about using it here until now...
I'll think about it again and I am fairly convident now that it can be solved better using either Rx or maybe even with one or two simple batching-block from TPL data-flow, as basically my case is (simplified) "send a batch of data now, if it is not already sending a batch" - the reason I did not use that until now is that I can not send a batch of data immediatly as soon as it is ready, but need to wait until my HW is ready to receive the next batch - and that is the case where I would have used the Taken
property, because I do not need to try sending another batch if the "old one" is still waiting for the HW and a "one time miss" because of the race condition wouldn't have mattered, because after all data is ready I loop a "wait some time and try sending a batch" until everything is sent...
from asyncex.
Related Issues (20)
- Contradiction? HOT 1
- Support AsyncProducerConsumerQueue wait for empty
- AsyncCollection IsEmpty HOT 3
- [Discussion] Return `ValueTask` instead of `AwaitableDisposable`? HOT 5
- [Question] .WaitAndUnwrapException() vs AsyncContext and potential deadlock HOT 2
- The collection has been marked as complete with regards to additions HOT 1
- Atomic wait semantics lead to continued processing after cancellation HOT 3
- What happened to NotifyTask? HOT 1
- CancellationTokenTaskSource's dispose
- Using LazyAsync with JSONSeralizer? HOT 1
- Producer/Consumer PriorityQueue
- doc/TaskConstants.md links to an article that doesn't exist anymore
- Cross thread Sync context stealing HOT 2
- [Question] Using discard with AsyncLock HOT 1
- [Question] Is ConfigureAwait(false) is needed? HOT 1
- AsyncContext holds exceptions until all tasks complete.
- Feature request: AsyncReaderWriterLock support for UpgradeableReadLock HOT 11
- The ApmAsyncFactory interop hangs if a path in async method returns synchronously. HOT 1
- Setting AsyncAutoResetEvent after used in Task.WhenAny HOT 3
- AsyncLazy with API call is being called twice across 4 components. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asyncex.