haiku/headers/private/system/thread_defs.h

56 lines
1.4 KiB
C
Raw Normal View History

/*
* Copyright 2008-2011, Ingo Weinhold, ingo_weinhold@gmx.de.
* Distributed under the terms of the MIT License.
*/
#ifndef _SYSTEM_THREAD_DEFS_H
#define _SYSTEM_THREAD_DEFS_H
#include <pthread.h>
#include <OS.h>
/** Size of the stack given to teams in user space */
#define USER_STACK_GUARD_SIZE (4 * B_PAGE_SIZE) // 16 kB
#define MIN_USER_STACK_SIZE (2 * B_PAGE_SIZE) // 8 kB
#define MAX_USER_STACK_SIZE (4096 * B_PAGE_SIZE) // 16 MB
#define USER_MAIN_THREAD_STACK_SIZE MAX_USER_STACK_SIZE
#define USER_STACK_SIZE (64 * B_PAGE_SIZE) // 256 kB
// The type of object a thread blocks on (thread::wait::type, set by
// thread_prepare_to_block()).
enum {
THREAD_BLOCK_TYPE_SEMAPHORE = 0,
THREAD_BLOCK_TYPE_CONDITION_VARIABLE = 1,
THREAD_BLOCK_TYPE_SNOOZE = 2,
THREAD_BLOCK_TYPE_SIGNAL = 3,
THREAD_BLOCK_TYPE_MUTEX = 4,
THREAD_BLOCK_TYPE_RW_LOCK = 5,
kernel: Properly separate and handle THREAD_BLOCK_TYPE_USER. Consider this scenario: * A userland thread puts its ID into some structure so that it can be woken up later, sets its wait_status to initiate the begin of the wait, and then calls _user_block_thread. * A second thread finishes whatever task the first thread intended to wait for, reads the ID almost immediately after it was written, and calls _user_unblock_thread. * _user_unblock_thread was called so soon that the first thread is not yet blocked on the _user_block_thread block, but is instead blocked on e.g. the thread's main mutex. * The first thread's thread_block() call returns B_OK. As in this example it was inside mutex_lock, it thinks that it now owns the mutex. * But it doesn't own the mutex, and so (until yesterday) all sorts of mayhem and then a random crash occurs, or (after yesterday) an assert-failure is tripped that the thread does not own the mutex it expected to. The above scenario is not a hypothetical, but is in fact the exact scenario behind the strange panics in #15211. The solution is to only have _user_unblock_thread actually unblock threads that were blocked by _user_block_thread, so I've introduced a new BLOCK_TYPE to differentiate these. While I'm at it, remove the BLOCK_TYPE_USER_BASE, which was never used (and now never will be.) If we want to differentiate different consumers of _user_block_thread for debugging purposes, we should use the currently-unused "object" argument to thread_block, instead of cluttering the relatively-clean block type debugging code with special types. One final note: The race condition which was the case of this bug does not, in fact, imply a deadlock on the part of the rw_lock here. The wait_status is protected by the thread's mutex, which is acquired by both _user_block_thread and _user_unblock_thread, and so if _user_unblock_thread succeeds faster than _user_block_thread can initiate the block, it will just see that wait_status is already <= 0 and return immediately. Fixes #15211.
2019-08-06 05:31:02 +03:00
THREAD_BLOCK_TYPE_USER = 6,
THREAD_BLOCK_TYPE_OTHER = 9999,
};
#define THREAD_CREATION_FLAG_DEFER_SIGNALS 0x01
// create the thread with signals deferred, i.e. with
// user_thread::defer_signals set to 1
struct thread_creation_attributes {
int32 (*entry)(void*, void*);
const char* name;
int32 priority;
void* args1;
void* args2;
void* stack_address;
size_t stack_size;
size_t guard_size;
pthread_t pthread;
uint32 flags;
};
#endif /* _SYSTEM_THREAD_DEFS_H */