Socket
Socket
Sign inDemoInstall

async-mutex

Package Overview
Dependencies
1
Maintainers
1
Versions
18
Alerts
File Explorer

Advanced tools

Install Socket

Detect and block malicious and high-risk dependencies

Install
2Next

0.5.0

Diff

Changelog

Source

0.5.0 - 2024/03/11

  • Support priority queueing for mutexes and semaphores. A huge "thank you" goes to @dmurvihill who added this feature.
  • Update dependencies.
dirtyhairy
published 0.4.1 •

Changelog

Source

0.4.1 - 2024/01/17

  • Expand documentation and fix a few errors.
  • Clear timeout after acquiring a lock in withTimeout.
  • Thanks to AkatQuas and aryzing for their contributions.
  • Update dependencies.
dirtyhairy
published 0.4.0 •

Changelog

Source

0.4.0 - 2022/09/02

This is a full rewrite of the core implementation.

  • Allow negative values for semaphores.
  • Allow weights for semaphore.acquire and semaphore.runExclusive. A waiter will be dispatched once the value of the semaphore is greater or equal to its weight.
  • Add semaphore.getValue and semaphore.setValue.
  • Allow weights for semaphore.waitForUnlock. The promise will only resolve once the value of the semaphore is greater or equal to its weight.
  • Only resolve waitForUnlock once no waiters remain (fixes #52).
  • waitForUnlock times out if the withTimeout decorator is used.
dirtyhairy
published 0.3.2 •

Changelog

Source

0.3.2 - 2021/08/30

  • Add waitForUnlock for waiting until a mutex/semaphore is free for locking, thanks to Jason Gore.
dirtyhairy
published 0.3.1 •

Changelog

Source

0.3.1 - 2021/02/22

  • withTimeout: make Jest happy and cancel timer when the mutex is acquired. Thanks to cantoine for the PR.
dirtyhairy
published 0.3.0 •

Changelog

Source

0.3.0 - 2021/02/05

  • Deprecate Mutex::release / Semaphore::release and remove them from the documentation. The methods are still available in 0.3.x, but will be removed in 0.4.0.

    I don't like breaking existing APIs, but using those methods is inherently dangerous as they can accidentally release locks acquired in a completely different place. Furthermore, they are mostly useless for semaphores. I consider adding them an unfortunate mistake on my end.

    A safe alternative is the usage of runExclusive which allows to execute blocks exclusively and automatically manages acquiring and releasing the mutex or semaphore.

  • Add Mutex::cancel / Semaphore::cancel for rejecting all currently pending locks.

  • Add tryAcquire decorator for lock-or-fail semantics.

dirtyhairy
published 0.2.6 •

Changelog

Source

0.2.6 - 2020/11/28

  • Fix a nasty bug related to consecutive calls to Mutex::release.
dirtyhairy
published 0.2.5 •

Changelog

Source

0.2.5 - 2020/11/28

  • Nothing new thanks to NPM. Go away. Install 0.2.6.
dirtyhairy
published 0.2.4 •

Changelog

Source

0.2.4 - 2020/07/09

  • Calling Semaphore::release on a semaphore with concurrency > 1 will not work as expected; throw an exception in this case
  • Make the warning on using Semaphore::release and Mutex::release more prominent
dirtyhairy
published 0.2.3 •

Changelog

Source

0.2.3 - 2020/06/18

  • Add alternate Semaphore::release and Mutex::release API
  • Work around build warnings with react native (and probably other bundlers)
2Next
SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc