haiku/headers/private/system/user_mutex_defs.h

/*
 * Copyright 2010, Ingo Weinhold, ingo_weinhold@gmx.de.
 * Distributed under the terms of the MIT License.
 */
#ifndef _SYSTEM_USER_MUTEX_DEFS_H
#define _SYSTEM_USER_MUTEX_DEFS_H


// flags passed to _kern_mutex_{un}block
// (same uint32 also used for B_TIMEOUT, etc.)
#define B_USER_MUTEX_SHARED			0x40000000
	// Mutex is in shared memory.
#define B_USER_MUTEX_UNBLOCK_ALL	0x80000000
	// All threads currently waiting on the mutex will be unblocked. The mutex
	// state will be locked.


// mutex value flags
#define B_USER_MUTEX_LOCKED		0x01
#define B_USER_MUTEX_WAITING	0x02
#define B_USER_MUTEX_DISABLED	0x04


#endif	/* _SYSTEM_USER_MUTEX_DEFS_H */
* Moved created subdirectory src/system/kernel/lock.cpp to new subdirectory locks. * Added syscalls for a new kind of mutex. A mutex consists only of an int32 and doesn't require any kernel resources. So it's initialization cannot fail (it consists only of setting the mutex value to 0). An uncontended lock or unlock operation can basically consist of an atomic_*() in userland. The syscalls (when the mutex is contended) are a bit more expensive than semaphore operations, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36158 a95241bf-73f2-0310-859d-f6bbb57e9c96 2010-04-11 20:07:39 +04:00			`/*`
			`* Copyright 2010, Ingo Weinhold, ingo_weinhold@gmx.de.`
			`* Distributed under the terms of the MIT License.`
			`*/`
			`#ifndef _SYSTEM_USER_MUTEX_DEFS_H`
			`#define _SYSTEM_USER_MUTEX_DEFS_H`


user_mutex: Per-team contexts. This requires the introduction of the flag B_USER_MUTEX_SHARED, and then actually using the SHARED flags in pthread structures to determine when it should be passed through. This commit still uses wired memory even for per-team contexts. That will change in the next commit. GLTeapot FPS seems about the same. Change-Id: I749a00dcea1531e113a65299b6d6610f57511fcc Reviewed-on: https://review.haiku-os.org/c/haiku/+/6602 Reviewed-by: waddlesplash <waddlesplash@gmail.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> 2023-06-13 19:43:00 +03:00			`// flags passed to _kern_mutex_{un}block`
user_mutex_defs: Add note that the flags area is shared with timeout flags. No functional change. 2023-06-19 23:40:33 +03:00			`// (same uint32 also used for B_TIMEOUT, etc.)`
user_mutex: Per-team contexts. This requires the introduction of the flag B_USER_MUTEX_SHARED, and then actually using the SHARED flags in pthread structures to determine when it should be passed through. This commit still uses wired memory even for per-team contexts. That will change in the next commit. GLTeapot FPS seems about the same. Change-Id: I749a00dcea1531e113a65299b6d6610f57511fcc Reviewed-on: https://review.haiku-os.org/c/haiku/+/6602 Reviewed-by: waddlesplash <waddlesplash@gmail.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> 2023-06-13 19:43:00 +03:00			`#define B_USER_MUTEX_SHARED 0x40000000`
			`// Mutex is in shared memory.`
* Moved created subdirectory src/system/kernel/lock.cpp to new subdirectory locks. * Added syscalls for a new kind of mutex. A mutex consists only of an int32 and doesn't require any kernel resources. So it's initialization cannot fail (it consists only of setting the mutex value to 0). An uncontended lock or unlock operation can basically consist of an atomic_*() in userland. The syscalls (when the mutex is contended) are a bit more expensive than semaphore operations, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36158 a95241bf-73f2-0310-859d-f6bbb57e9c96 2010-04-11 20:07:39 +04:00			`#define B_USER_MUTEX_UNBLOCK_ALL 0x80000000`
			`// All threads currently waiting on the mutex will be unblocked. The mutex`
			`// state will be locked.`


			`// mutex value flags`
			`#define B_USER_MUTEX_LOCKED 0x01`
			`#define B_USER_MUTEX_WAITING 0x02`
			`#define B_USER_MUTEX_DISABLED 0x04`


			`#endif /* _SYSTEM_USER_MUTEX_DEFS_H */`