# Monitor ConditionVariable Contract Clarification **URL:** \ **Category:** ruby-talk\ **Created:** [24 February 2009 07:45 UTC](https://rubytalk.org/t/monitor-conditionvariable-contract-clarification/51930 "2009-02-24T07:45:44Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Arya\_Asemanfar](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@Arya\_Asemanfar](https://rubytalk.org/u/Arya_Asemanfar)\ **Post date:** [24 February 2009 07:45 UTC](https://rubytalk.org/t/monitor-conditionvariable-contract-clarification/51930/1 "2009-02-24T07:45:44Z")
I ran into a race case while using the Monitor library and was wonder if it was a violation of the Monitor module's contract or my misunderstanding of the contract. Scenario: Thread A grabs the mutex lock, then enters a wait with a ConditionVariable. Thread B then grabs the mutex lock and signals that same ConditionVariable. Thread C tries to grab the mutex lock using synchronize. My question is: is Thread A supposed to be guaranteed access to the lock before any other threads assuming Thread A was the only thread in that ConditionVariable's waiting queue? I've spent quite sometime going through the Monitor module's implementation and it seems that the intention of the following method was to enforce that waiting threads get control of the mutex before entering thrads.   def mon\_release     @mon\_owner = nil     t = @mon\_waiting\_queue.shift     t = @mon\_entering\_queue.shift unless t     t.wakeup if t   end But because there is a critical section gap between when Thread B calls signal and Thread A enters its critical section, another Thread could have grabbed the lock. If this is the intended behavior, is there a common pattern for achieving what I need? Thank you, Arya > **ยทยทยท** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).