libroot: Do not rely on thread_yield()

This commit is contained in:
Pawel Dziepak 2013-10-09 02:07:08 +02:00
parent 879ceb60d8
commit 3e91b082c8
4 changed files with 10 additions and 26 deletions

View File

@ -1,6 +1,6 @@
SubDir HAIKU_TOP src system libroot posix malloc ;
UsePrivateHeaders libroot ;
UsePrivateHeaders libroot shared ;
local architectureObject ;
for architectureObject in [ MultiArchSubDirSetup ] {

View File

@ -41,12 +41,6 @@ void *(*sbrk_hook)(long) = &BPrivate::hoardSbrk;
using namespace BPrivate;
// How many iterations we spin waiting for a lock.
enum { SPIN_LIMIT = 50 };
// The values of a user-level lock.
enum { UNLOCKED = 0, LOCKED = 1 };
struct free_chunk {
free_chunk *next;
size_t size;
@ -368,35 +362,21 @@ hoardUnsbrk(void *ptr, long size)
void
hoardLockInit(hoardLockType &lock, const char *name)
{
lock = UNLOCKED;
mutex_init(&lock, name);
}
void
hoardLock(hoardLockType &lock)
{
// A yielding lock (with an initial spin).
while (true) {
int32 i = 0;
while (i < SPIN_LIMIT) {
if (atomic_test_and_set(&lock, LOCKED, UNLOCKED) == UNLOCKED) {
// We got the lock.
return;
}
i++;
}
// The lock is still being held by someone else.
// Give up our quantum.
hoardYield();
}
mutex_lock(&lock);
}
void
hoardUnlock(hoardLockType &lock)
{
atomic_set(&lock, UNLOCKED);
mutex_unlock(&lock);
}

View File

@ -27,8 +27,12 @@
#include <OS.h>
#include <assert.h>
#include <locks.h>
typedef int32 hoardLockType;
// TODO: some kind of adaptive mutex (i.e. trying to spin for a while before
// may be a better choice
typedef mutex hoardLockType;
namespace BPrivate {

View File

@ -46,7 +46,7 @@ using namespace BPrivate;
#if HEAP_LEAK_CHECK
static block* sUsedList = NULL;
static hoardLockType sUsedLock = 0;
static hoardLockType sUsedLock = MUTEX_INITIALIZER("");
/*!