Monitor ConditionVariable Contract Clarification

A

Arya Asemanfar

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,236
Members
46,821
Latest member
AleidaSchi

Latest Threads

Top