gecko-dev/xpcom/threads/nsEventQueue.cpp

147 lines
3.7 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 11:12:37 +00:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#include "nsEventQueue.h"
#include "nsAutoPtr.h"
#include "mozilla/Logging.h"
#include "nsThreadUtils.h"
#include "prthread.h"
#include "mozilla/ChaosMode.h"
using namespace mozilla;
static LazyLogModule sEventQueueLog("nsEventQueue");
#ifdef LOG
#undef LOG
#endif
#define LOG(args) MOZ_LOG(sEventQueueLog, mozilla::LogLevel::Debug, args)
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
nsEventQueue::nsEventQueue(Mutex& aLock)
: mHead(nullptr)
, mTail(nullptr)
, mOffsetHead(0)
, mOffsetTail(0)
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
, mEventsAvailable(aLock, "[nsEventQueue.mEventsAvailable]")
{
}
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
nsEventQueue::~nsEventQueue()
{
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
// It'd be nice to be able to assert that no one else is holding the lock,
// but NSPR doesn't really expose APIs for it.
NS_ASSERTION(IsEmpty(),
"Non-empty event queue being destroyed; events being leaked.");
if (mHead) {
FreePage(mHead);
}
}
bool
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
nsEventQueue::GetEvent(bool aMayWait, nsIRunnable** aResult,
MutexAutoLock& aProofOfLock)
{
while (IsEmpty()) {
if (!aMayWait) {
if (aResult) {
*aResult = nullptr;
}
return false;
}
LOG(("EVENTQ(%p): wait begin\n", this));
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
mEventsAvailable.Wait();
LOG(("EVENTQ(%p): wait end\n", this));
}
if (aResult) {
MOZ_ASSERT(mOffsetHead < EVENTS_PER_PAGE);
MOZ_ASSERT_IF(mHead == mTail, mOffsetHead <= mOffsetTail);
*aResult = mHead->mEvents[mOffsetHead++];
MOZ_ASSERT(*aResult);
MOZ_ASSERT(mOffsetHead <= EVENTS_PER_PAGE);
// Check if mHead points to empty Page
if (mOffsetHead == EVENTS_PER_PAGE) {
Page* dead = mHead;
mHead = mHead->mNext;
FreePage(dead);
mOffsetHead = 0;
}
}
return true;
1999-06-04 15:02:27 +00:00
}
void
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
nsEventQueue::PutEvent(already_AddRefed<nsIRunnable>&& aRunnable,
MutexAutoLock& aProofOfLock)
{
if (!mHead) {
mHead = NewPage();
MOZ_ASSERT(mHead);
mTail = mHead;
mOffsetHead = 0;
mOffsetTail = 0;
} else if (mOffsetTail == EVENTS_PER_PAGE) {
Page* page = NewPage();
MOZ_ASSERT(page);
mTail->mNext = page;
mTail = page;
mOffsetTail = 0;
}
nsIRunnable*& queueLocation = mTail->mEvents[mOffsetTail];
MOZ_ASSERT(!queueLocation);
queueLocation = aRunnable.take();
++mOffsetTail;
LOG(("EVENTQ(%p): notify\n", this));
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
mEventsAvailable.Notify();
}
void
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
nsEventQueue::PutEvent(nsIRunnable* aRunnable, MutexAutoLock& aProofOfLock)
{
nsCOMPtr<nsIRunnable> event(aRunnable);
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
PutEvent(event.forget(), aProofOfLock);
}
size_t
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
2015-09-20 09:13:09 +00:00
nsEventQueue::Count(MutexAutoLock& aProofOfLock)
{
// It is obvious count is 0 when the queue is empty.
if (!mHead) {
return 0;
}
/* How we count the number of events in the queue:
* 1. Let pageCount(x, y) denote the number of pages excluding the tail page
* where x is the index of head page and y is the index of the tail page.
* 2. Then we have pageCount(x, y) = y - x.
*
* Ex: pageCount(0, 0) = 0 where both head and tail pages point to page 0.
* pageCount(0, 1) = 1 where head points to page 0 and tail points page 1.
*
* 3. number of events = (EVENTS_PER_PAGE * pageCount(x, y))
* - (empty slots in head page) + (non-empty slots in tail page)
* = (EVENTS_PER_PAGE * pageCount(x, y)) - mOffsetHead + mOffsetTail
*/
int count = -mOffsetHead;
// Compute (EVENTS_PER_PAGE * pageCount(x, y))
for (Page* page = mHead; page != mTail; page = page->mNext) {
count += EVENTS_PER_PAGE;
}
count += mOffsetTail;
MOZ_ASSERT(count >= 0);
return count;
}