* The run when pushing a commit bumping the concurrent-ruby version fails
  as the workflow relies on the tag to exist, but the tag is created
  later in the release process.
  So just re-run this workflow automatically when the tag is pushed.

…ansients

Bumps [actions/deploy-pages](https://github.com/actions/deploy-pages) from 4 to 5.
- [Release notes](https://github.com/actions/deploy-pages/releases)
- [Commits](actions/deploy-pages@v4...v5)

---
updated-dependencies:
- dependency-name: actions/deploy-pages
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/upload-pages-artifact](https://github.com/actions/upload-pages-artifact) from 4 to 5.
- [Release notes](https://github.com/actions/upload-pages-artifact/releases)
- [Commits](actions/upload-pages-artifact@v4...v5)

---
updated-dependencies:
- dependency-name: actions/upload-pages-artifact
  dependency-version: '5'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: Joshua Young <djry1999@gmail.com>

`release_write_lock` did not verify ownership, so any thread with a
reference to the lock could clear the `RUNNING_WRITER` bit while the
original writer was still inside its critical section. A second writer
could then acquire and run concurrently, breaking write exclusivity.

`release_read_lock` decremented `@Counter` unconditionally. On a fresh
lock the counter dropped to -1, after which `max_readers?` saw
`-1 & MAX_READERS == MAX_READERS` and blocked all subsequent acquires
with `ResourceLimitError`.

Track the write owner in an `AtomicReference` and raise
`IllegalOperationError` from `release_write_lock` when the calling
thread does not hold it, covering both the wrong-thread and never-held
cases. Raise the same error from `release_read_lock` when no read
lock is currently held, matching how `ReentrantReadWriteLock` already
detects this via its per-thread `@HeldCount`.

The numeric `compare_and_set` wrapper checks `old == old_value` before
delegating to `_compare_and_set`. With `Float::NAN` that check is
always false (`NaN != NaN`), so `#update` retries indefinitely.

Handle expected NaN explicitly so `#update` can terminate.

The per-thread `@HeldCount` packs the read hold count into the low 15
bits and uses bit 15 as `WRITE_LOCK_HELD`. The reentrant paths in
`acquire_read_lock` and `try_read_lock` incremented `@HeldCount`
without bounding the read portion, so after 32,768 reentrant read
holds the count overflowed into `WRITE_LOCK_HELD`. A subsequent
`try_write_lock` or `acquire_write_lock` would then take the "already
hold a write lock" fast path and return true without setting
`RUNNING_WRITER`, silently violating write exclusivity.

Raise `ResourceLimitError` when the local read count would overflow,
matching how the cold path handles global reader exhaustion.

…n JRuby and TruffleRuby