Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

ensure improperly locking ref

Description

For example:

Clojure 1.6.0-beta1 user=> (def r (ref 0)) #'user/r user=> (dosync (ensure r)) SynchronizationLockException The read lock is being released without being held. System.Threading.ReaderWriterLockSlim. ExitReadLock (:0)

I'm fairly certain the call to Lock(r) in LockingTransaction.DoEnsure is incorrect. I believe it should be r.EnterReadLock()

Environment

None

Activity

Show:

David MillerJune 21, 2014 at 6:31 PM

David MillerJune 21, 2014 at 6:30 PM

It is correct that the call to Lock(r) in LockingTransaction.DoEnsure should be r.EnterReadLock()instead.
Dates back to a change in the JVM version in 2009. https://github.com/clojure/clojure/commit/961743446562b6fa7be25f96de02aacd626169da
I missed the change in call when I was editing.

This reveals the need for LockRecursionPolicy.SupportsRecursion.

Greg ChapmanJune 18, 2014 at 9:04 PM

Also, it seems that Refs' locks have to support recursion (LockRecursionPolicy.SupportsRecursion). An ensured ref has its readlock held; any attempt to deref it (in the same transaction) will attempt to reobtain the readlock (in Ref.currentVal().

Completed

Details

Assignee

Reporter

Priority

Created June 18, 2014 at 8:17 PM
Updated June 21, 2014 at 6:31 PM
Resolved June 21, 2014 at 6:31 PM