Forum: Ruby Monitor ConditionVariable Contract Clarification

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Arya A. (Guest)
on 2009-02-24 09:46
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
This topic is locked and can not be replied to.