This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Really two related RFEs: Some provision in Mutex (set in constructor perhaps so only available to creator and holder of mutex) for finding out when the mutex is acquired and released, and in which mode. Could be useful e.g. for batching up change events until a mutex is released for efficiency. boolean Mutex.have{Read,Write}Access(). Should tell you if the current thread is currently inside the dynamic scope of a reader or writer, resp. Of course if it is inside the scope of a writer, then haveReadAccess() would be true as well.
I guess Ales knows a lot about Mutex, provisionally assigning to you.
Target milestone -> 3.3.1.
Set target milestone to TBD
In issue #32439 patch: - canRead() and canWrite() are implemented - postReadRequest() is probably enough to batch up change firing from within a write mutex; it will be run in the read mutex just after exiting the (outermost) write mutex but before returning from the method which exited that write mutex; other readers can be running during it, but that is probably OK, since if you needed them to have all changes fired to them before they saw the new state, then you should have fired changes synch anyway (or else reader code running deeply within the write mutex might see the wrong result)
Prefer not to touch existing Mutex API; rather create a cleaner replacement.
boolean Mutex.have{Read,Write}Access() would not mean any change to semantics. Please reconsider reopening.
Would be a safe semantic addition, true, but it would mean adding such methods to the old Mutex codebase. I certainly do not want to attempt that. If you want to, go ahead.