server-skynet-source-3rd-je.../src/mutex_pool.c

#define JEMALLOC_MUTEX_POOL_C_

#include "jemalloc/internal/jemalloc_preamble.h"
#include "jemalloc/internal/jemalloc_internal_includes.h"

#include "jemalloc/internal/mutex.h"
#include "jemalloc/internal/mutex_pool.h"

bool
mutex_pool_init(mutex_pool_t *pool, const char *name, witness_rank_t rank) {
	for (int i = 0; i < MUTEX_POOL_SIZE; ++i) {
		if (malloc_mutex_init(&pool->mutexes[i], name, rank,
		    malloc_mutex_address_ordered)) {
			return true;
		}
	}
	return false;
}
Protect the rtree/extent interactions with a mutex pool. Instead of embedding a lock bit in rtree leaf elements, we associate extents with a small set of mutexes. This gets us two things: - We can use the system mutexes. This (hypothetically) protects us from priority inversion, and lets us stop doing a backoff/sleep loop, instead opting for precise wakeups from the mutex. - Cuts down on the number of mutex acquisitions we have to do (from 4 in the worst case to two). We end up simplifying most of the rtree code (which no longer has to deal with locking or concurrency at all), at the cost of additional complexity in the extent code: since the mutex protecting the rtree leaf elements is determined by reading the extent out of those elements, the initial read is racy, so that we may acquire an out of date mutex. We re-check the extent in the leaf after acquiring the mutex to protect us from this race. 2017-05-16 05:23:51 +08:00			`#define JEMALLOC_MUTEX_POOL_C_`

			`#include "jemalloc/internal/jemalloc_preamble.h"`
			`#include "jemalloc/internal/jemalloc_internal_includes.h"`

Header refactoring: unify and de-catchall mutex module 2017-05-24 03:28:19 +08:00			`#include "jemalloc/internal/mutex.h"`
Header refactoring: unify and de-catchall mutex_pool. 2017-05-24 05:56:24 +08:00			`#include "jemalloc/internal/mutex_pool.h"`
Header refactoring: unify and de-catchall mutex module 2017-05-24 03:28:19 +08:00
Protect the rtree/extent interactions with a mutex pool. Instead of embedding a lock bit in rtree leaf elements, we associate extents with a small set of mutexes. This gets us two things: - We can use the system mutexes. This (hypothetically) protects us from priority inversion, and lets us stop doing a backoff/sleep loop, instead opting for precise wakeups from the mutex. - Cuts down on the number of mutex acquisitions we have to do (from 4 in the worst case to two). We end up simplifying most of the rtree code (which no longer has to deal with locking or concurrency at all), at the cost of additional complexity in the extent code: since the mutex protecting the rtree leaf elements is determined by reading the extent out of those elements, the initial read is racy, so that we may acquire an out of date mutex. We re-check the extent in the leaf after acquiring the mutex to protect us from this race. 2017-05-16 05:23:51 +08:00			`bool`
			`mutex_pool_init(mutex_pool_t pool, const char name, witness_rank_t rank) {`
			`for (int i = 0; i < MUTEX_POOL_SIZE; ++i) {`
			`if (malloc_mutex_init(&pool->mutexes[i], name, rank,`
			`malloc_mutex_address_ordered)) {`
			`return true;`
			`}`
			`}`
			`return false;`
			`}`