Stop using ThreadCondition in BlockAllocator

• Component: New Bugs
• Status: RESOLVED FIXED

[Anders Carlsson]

Stop using ThreadCondition in BlockAllocator

[Anders Carlsson]

Created attachment 220136 [details]
Patch

[Anders Carlsson]

Created attachment 220138 [details]
Patch

[Anders Carlsson]

Committed r161161: <http://trac.webkit.org/changeset/161161>

[Alexey Proskuryakov]

Rolled out with the rest of today's threading fixes, which broke WebKit2 on Mountain Lion.

I don't know if this particular change caused any trouble - there was so much churn today that I could't tell which patch caused which badness. Perhaps we should simply re-land if we can get EWS green.

I think that r161163 was a follow-up fix to this.

[Filip Pizlo]

Comment on attachment 220138 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=220138&action=review

> Source/JavaScriptCore/heap/BlockAllocator.cpp:106
> +    std::unique_lock<std::mutex> lock(m_emptyRegionConditionMutex);

Why is this a unique_lock instead of lock_guard?

[Anders Carlsson]

(In reply to comment #5)
> (From update of attachment 220138 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=220138&action=review
> 
> > Source/JavaScriptCore/heap/BlockAllocator.cpp:106
> > +    std::unique_lock<std::mutex> lock(m_emptyRegionConditionMutex);
> 
> Why is this a unique_lock instead of lock_guard?

Unique locks are used together with std::condition_variable.

[Anders Carlsson]

Committed r162362: <http://trac.webkit.org/changeset/162362>