History log of /haiku/src/system/kernel/condition_variable.cpp
Revision Date Author Comments
# 6a479447 30-Jan-2024 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Add another check of the wait status after _RemoveFromVariable.

If it was set, we want to return it.


# 6d306550 04-Aug-2023 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Adjust notified count and wait-status returning.

* If we received a wait status, always return with it.

* Only count those entries for which we set the wait-status as
having been notified.

In conjunction with the prior commit, this fixes some rare deadlocks
that could occur with timeouts or signals.


# aca21731 25-Jul-2023 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Return the count of unblocked threads from Notify.

No reason not to, and it's needed in user_mutex to avoid a very rare
potential race, anyway.


# 6554d744 13-Jun-2023 Augustin Cavalier <waddlesplash@gmail.com>

kernel: Print the first 4 chars of cvar names in KDL "threads" command.

Condition variables are now a pretty common way the kernel blocks threads.
That means the "threads" command was getting difficult to navigate, since
at any given time, a lot of threads could be blocked on "cvar".

Now we try (carefully, because it could fault!) to fetch the first 4
characters of the "type" name and display then. This suffices to
distinguish the most common object block types in the list at a glance
(e.g. "cvar:port" for port reads, the most common.)

Change-Id: I94f4b59fd78b7ebdce913944551a5e98f0ca2e33
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6605
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# 9747721a 26-Apr-2023 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Add a fast-exit from Wait() for negative timeouts.

acquire_sem_etc does something very similar.


# acfde459 25-Apr-2022 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Downgrade another panic into a debug print.

Fixes #17686.


# bb09a3ed 09-Mar-2022 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Remove a confusing requirement for published variables.

Part of the point of published variables is to make them "shareable",
and not require external synchronization. Requiring the callers
to ensure unpublishing does not occur is thus unreasonable, as e.g.
a variable could be unpublished immediately after being notified.

That is the case for some usages of these variables in the FreeBSD
compatibility layer, which under heavy usage, can and did trigger
use-after-unpublishes and then KDLs, at least in local testing.

Instead, only unlock the hash after we have locked the variable.
This is already done in some other functions, so it's safe to do
it here, too. This way, the variable won't be unpublished
while Notify() is running.


# 50157a8d 07-Feb-2022 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Make ConditionVariableEntry::Variable non-inline.

We have to use an atomic here.


# c9d521ea 07-Feb-2022 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Various cleanups.

* Adjust a comment that now goes with 3 functions and not just 1.

* Remove spinlock switch function, this is useless as it cannot
change interrupt states here, but we require interrupts to
be enabled to wait on a ConditionVariable.

* Remove WaitStatus function from ConditionVariableEntry; unused
and would require locks anyway.

* Implement Publish using Init.


# a8d965a0 03-Feb-2022 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Borrow the scheduler lock instead of self-unblocking.

Self-unblocking is not done anywhere else in the kernel and may not be
such a bright idea, it seems.

This also allows the elimination of some atomics, and resolves a race
that otherwise would have required another wait-loop. Performance
differences seem to be within the realm of noise.

Fixes #17553.

Change-Id: Id719ba51ed3f2a15557c8d53947182a5f8879b7b


# d03e5994 29-Jan-2022 X512 <danger_mail@list.ru>

ConditionVariable: add classical wait interface with lockable

Change-Id: Id18264e786dba818138caf3908c7a89b18e2a1dd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4921
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# 2472048e 27-Jan-2022 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Add missing newline in debug print.


# 49ddb1ff 26-Jan-2022 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Downgrade one of the panics into a dprintf.

On some virtualized systems, this seems to still occur,
and at this point may not be preventable.

Fixes #17455.


# e0842c10 17-Dec-2021 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Pause between iterations.

Should hopefully resolve the remaining problem in #17455.

Change-Id: I6e00286508c069705e07c9a0b59af2cf5e15e427
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4819
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>


# 7959ac39 08-Dec-2021 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Unblock after unset, if possible.

The previous round of this code unblocked after unset universally,
but that was incorrect in the case where the thread was not in
the "waiting" state before we unset. Yesterday I changed that to
just unblock before unset universally.

It seems, however, that thread_unblock is so time-consuming
that the other thread will wake up and begin doing things
before unblock returns for us, and then it will hit the timeout
before we have a chance to unset. So, now we unblock later
if it is possible to do so.

It seems very strange, though, that thread_unblock will
not return in a small but significant number of cases
before the unblocked thread actually starts running (note
that we are in interrupts-disabled mode here, so that is
not the problem.) That sounds like a problem for another day.

Should fix #17455, possibly in tandem with the previous commit.


# 14552630 08-Dec-2021 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Increase tries count.

Should help with timeout panics occurring, at least somewhat.


# 7ce3c928 07-Dec-2021 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Unblock earlier and simplify the code more.

Unblocking after unsetting fVariable just causes too many headaches
and corner cases to deal with; the code as-is did not actually handle
all of them, as it missed the case where the entry thread had called
thread_prepare_to_block but had not yet actually blocked.

Hopefully the last fix for #17444.


# acdd232a 07-Dec-2021 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Check thread->state before unblock.

See inline comments. Should help with #17444.


# 858210da 06-Dec-2021 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Acquire thread->scheduler_lock before unsetting fVariable.

This fixes a race condition as described in the inline comment.

Hopefully fixes #17444.


# 02077ffc 23-Nov-2021 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Atomicize ConditionVariableEntry and drop the lock.

Before 2019, the entire ConditionVariable system was "giant"-locked:
that is, there was a single global lock that all ConditionVariable
and ConditionVariableEntry operations had to pass through. This of
course was not very performant on multicore systems and when
ConditionVariables see significant use, so I reworked it then to have
more granular locking.

Those patches took a number of attempts to get right, as having two
objects in separate threads that can each access the other not turn
into a deadlock or use-after-free is not easy to say the least,
and the ultimate solution I came up with erased most of the performance
gains I initially saw on the first (partially broken) patchsets.

So I have wanted to revisit this and see if there was a better way
even since then. Recently there have been a few reports of
ConditionVariable-related panics (apparently double unlocks),
notably #16894, and so that was reason enough to actually revisit
this code and see if a better solution could be found.

Well, I think I have come up with one: after this commit, Entries
no longer have their own lock, and instead accesses to Entry members
are almost always atomic; and there is now a case where we spin inside
Variable::_NotifyLocked as well as one in Entry::_RemoveFromVariable.

This leads to somewhat simpler code (no more lock/unlock dance in Notify),
though it is significantly more difficult to understand the nuances of it,
so I have left a sizable number of comments explaining the intricacies
of the new logic.

Note: I initially tried 1000 for "tries", but on a few instances I did see
the panic hit, strangely. I don't think the code that is waited on can
be reasonably reduced any further, so I have just increased the limit to
10000 (which is still well below what spinlocks use.) Hopefully this suffices.

Quick benchmark, x86, compiling HaikuDepot and the mime_db in VMware, 2 cores:
before:
real 0m23.627s
user 0m25.152s
sys 0m7.319s

after:
real 0m23.962s
user 0m25.229s
sys 0m7.330s

Though I occasionally I saw sys times as low as 7.171s, so this seems
to be at least not a regression if not a definitive improvement.

Change-Id: Id042947976885cd5c1433cc4290bdf41b01ed10e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4727
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>


# 1728b8c7 01-Mar-2020 Augustin Cavalier <waddlesplash@gmail.com>

kernel: Rework ConditionVariableEntry destruction.

It is no longer an error to destroy a ConditionVariableEntry
that is still attached to a ConditionVariable; it will
now be implicitly detached in that case.

This makes ConditionVariableEntrys much eaiser to use
from an API standpoint.

Change-Id: I03c676d3a198aa885de733d3e1729b15f80de031
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2301
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# af0be8db 05-Aug-2019 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Clean up comments and reduce needless unlocks.

This "race prevention" code does not seem to be really hit at all
in practice, at least from testing, so no need to do a full
unlock/lock universally for it.

I'm still not sure why the previous fixes here removed 80% of
the performance benefits of the original change; I need to
investigate that more.


# 9dc67a1d 04-Aug-2019 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Rework remove-from-condition logic again.

This avoids a few potential race conditions mmlr pointed out on
the mailing list. See inline comments.

Change-Id: I605523c1d2683c749751599c417a68a20c70edea


# 28742827 03-Aug-2019 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Acquire and release locks in the right order.

Should fix #15223.


# 37eda488 03-Aug-2019 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Granularize locking.

Before this commit, *all* ConditionVariable operations (yes, all;
even Wait, Notify, etc.) went through a single spinlock, that also
protected the sConditionVariableHash. This obviously does not scale
so well with core count, to say the least!

With this commit, we add spinlocks to each Variable and Entry.
This makes locking somewhat more complicated (and nuanced; see
inline comment), but the trade-off seems completely worth it:

(compile HaikuDepot in VMware, 2 cores)
before
real 1m20.219s
user 1m5.619s
sys 0m40.724s

after
real 1m12.667s
user 0m57.684s
sys 0m37.251s

The more cores there are, the more of an optimization this will
likely prove to be. But 10%-across-the-board is not bad to say
the least.

Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a


# 489612d4 03-Aug-2019 Augustin Cavalier <waddlesplash@gmail.com>

kernel/condition_variable: Reorder some methods.

This way the static functions (used only in KDL) are below
the actual notification methods, which are now all grouped
together in one place.

No functional change.


# 03fb2d88 07-Nov-2013 Pawel Dziepak <pdziepak@quarnos.org>

kernel: Remove gSchedulerLock

* Thread::scheduler_lock protects thread state, priority, etc.
* sThreadCreationLock protects thread creation and removal and list of
threads in team.
* Team::signal_lock and Team::time_lock protect list of threads in team
as well.
* Scheduler uses its own internal locking.


# 11cacd0c 04-Nov-2013 Pawel Dziepak <pdziepak@quarnos.org>

kernel: Remove thread_block_with_timeout_locked()


# 0e88a887 13-Jun-2012 Alex Smith <alex@alex-smith.me.uk>

First round of 64-bit safety fixes in the kernel.

* Most of this is incorrect printf format strings. Changed all strings
causing errors to use the B_PRI* format string definitions, which
means the strings should be correct across all platforms.
* Some other fixes for errors, casts required, etc.


# 24df6592 11-Jun-2011 Ingo Weinhold <ingo_weinhold@gmx.de>

Merged signals-merge branch into trunk with the following changes:
* Reorganized the kernel locking related to threads and teams.
* We now discriminate correctly between process and thread signals. Signal
handlers have been moved to teams. Fixes #5679.
* Implemented real-time signal support, including signal queuing, SA_SIGINFO
support, sigqueue(), sigwaitinfo(), sigtimedwait(), waitid(), and the addition
of the real-time signal range. Closes #1935 and #2695.
* Gave SIGBUS a separate signal number. Fixes #6704.
* Implemented <time.h> clock and timer support, and fixed/completed alarm() and
[set]itimer(). Closes #5682.
* Implemented support for thread cancellation. Closes #5686.
* Moved send_signal() from <signal.h> to <OS.h>. Fixes #7554.
* Lots over smaller more or less related changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42116 a95241bf-73f2-0310-859d-f6bbb57e9c96


# af983c17 03-Dec-2009 Colin Günther <coling@gmx.de>

Coding style cleanups. Thanks axeld.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34462 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1581b764 02-Dec-2009 Colin Günther <coling@gmx.de>

* Adding static Notify{One,All} functions. This allows a cleaner implementation
of the condition variable and synchronization subsystem of the freebsd compat
layer which will be committed next.
* Also there was a discussion about adding these functions on the commit
mailing list. The mail in http://www.freelists.org/post/haiku-commits/r34395-in-haikutrunksrclibscompatfreebsd-network-compatsys,3
is a good sum up of it (need to scroll somewhat down, though).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34458 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5ee1f125 21-Oct-2009 Michael Lotz <mmlr@mlotz.ch>

Make use of the wait status field so it can be provided in Notify() and then
read out in the ConditionVariableEntry::WaitStatus(). That way you can notify
with a specific status that can be read out on the other end.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33718 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5147963d 26-Jul-2009 Stephan Aßmus <superstippi@gmx.de>

headers/private/kernel/util/OpenHashTable.h, Hugo's version, is a bit nicer than
Tracker's OpenHashTable.h which it should eventually replace. We've renamed the
class to BOpenHashTable and changed the interface slightly so that HashTableLink
became superfluous.
Adapted all the code that used it. Since the OpenHashTables no longer clash,
this should fix the GCC4 build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31791 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 227fe7d3 23-Apr-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

* Scheduler/wait object listener:
- Moved scheduler listening interface to <listeners.h> and added more
convenient to use templatized notification functions.
- Added a listener mechanism for the wait objects (semaphores, condition
variables, mutex, rw_lock).
* system profiler:
- Hopefully fixed locking issues related to notifying the profiler thread
for good. We still had an inconsistent locking order, since the scheduler
notification callbacks are invoked with the thread lock held and have to
acquire the object lock then, while the other callbacks acquired the object
lock first and as a side effect of ConditionVariable::NotifyOne() acquired
the thread lock. Now we make sure the object lock is the innermost lock.
- Track the number of dropped events due to a full buffer.
_user_system_profiler_next_buffer() returns this count now.
- When scheduling profiling events are requested also listen to wait objects
and generate the respective profiling events. We send those events lazily
and cache the infos to avoid resending an event for the same wait object.
- When starting profiling we do now generate "thread scheduled" events for
the already running threads.
- _user_system_profiler_start(): Check whether the parameters pointer is a
userland address at all.
- The system_profiler_team_added event does now also contain the team's name.
* Added a sem_get_name_unsafe() returning a semaphore's name. It is "unsafe",
since the caller has to ensure that the semaphore exists and continues to
exist as long as the returned name is used.
* Adjusted the "profile" and "scheduling_recorder" according to the system
profiling changes. The latter prints the number of dropped events, now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30345 a95241bf-73f2-0310-859d-f6bbb57e9c96


# fd0803f3 06-Apr-2009 Axel Dörfler <axeld@pinc-software.de>

* Added RemoveTail() method.
* Renamed DoublyLinkedList::Size() to Count(), since it actually counts the
items (ie. O(n)).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29979 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 020ac568 03-Sep-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Fixed bug in the "scheduler" command: The check when a thread was
unscheduled was incorrect.
* Introduced _kern_analyze_scheduling() syscall. It requires scheduler
kernel tracing to be enabled. It uses the tracing entries for a given
period of time to do a similar analysis the "scheduler" debugger
command does (i.e. number of runs, run time, latencies, preemption
times) for each thread. Additionally the analysis includes for each
thread how long the thread waited on each locking primitive in total.
* Added kernel tracing for the creation of semaphores and initialization
of condition variables, mutexes, and rw locks. The enabling macro is
SCHEDULING_ANALYSIS_TRACING. The only purpose is to provide
_kern_analyze_scheduling() with more info on the locking primitives
(the name in particular).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27304 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1a617f51 03-Aug-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

More informative panic().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26773 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 15374c5d 02-Aug-2008 Axel Dörfler <axeld@pinc-software.de>

* Renamed thread_spinlock and team_spinlock to gThreadSpinlock and
gTeamSpinlock.
* Renamed the static global variables in smp.c to match our style guide.
* Minor other cleanup.
* Removed superfluous white space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26730 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8cc3c744 28-Jul-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

The "cvar" command wasn't happy with private condition variables. Now we
don't check any longer whether the given number is the address of a
condition variable in the global hash table; we just assume it is a
valid condition variable pointer.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26674 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5c99d639 22-Jul-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Merged branch haiku/branches/developer/bonefish/vm into trunk. This
introduces the following relevant changes:
* VMCache:
- Renamed vm_cache to VMCache, merged it with vm_store and made it a
C++ class with virtual methods (replacing the store operations).
Turned the different store implementations into subclasses.
- Introduced MergeStore() callback, changed semantics of Commit().
- Changed locking and referencing semantics. A reference can only be
acquired/released with the cache locked. An unreferenced cache is
deleted and a mergeable cache merged when it is unlocked. This
removes the "busy" state of a cache and simplifies the page fault
code.
* Added VMAnonymousCache, which will implement swap support (work by
Zhao Shuai). It is not integrated and used yet, though.
* Enabled the mutex/recursive lock holder asserts.
* Fixed DoublyLinkedList::Swap().
* Generalized the low memory handler to a low resource handler. And made
semaphores and reserved memory handled resources. Made
vm_try_resource_memory() optionally wait (with timeout), and used that
feature to reserve memory for areas.
...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26572 a95241bf-73f2-0310-859d-f6bbb57e9c96


# cb919155 16-Jul-2008 Axel Dörfler <axeld@pinc-software.de>

bonefish + axeld:
* Removed the superfluous "flags" parameter from ConditionVariable::Add()
that we forgot there when we moved the flags field from
ConditionVariableEntry::Add() to Wait().
* Using this method was therefore not a good idea - only UnixFifo did, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26454 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 276aa463 24-Jun-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Replaced the useless InitCheck() method in {Open,Multi}HashTable (it
always returned B_OK) by a Init() method, which sets the initial size
and returns an error, if that fails.
* Adjusted code using the classes accordingly. Replaced a few
InitCheck() methods in the network code by Init().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26127 a95241bf-73f2-0310-859d-f6bbb57e9c96


# fbe0c27a 17-May-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

axeld + bonefish:
Changed condition variables so that it is allowed to block (e.g. lock
mutexes etc.) between Add() and Wait(). This fixes #2059, since the
block writer used them this way and could thusly fail to wait for a
condition variable, causing a temporary stack object to be used past its
lifetime.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25525 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 023bf5fc 22-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added support for timeouts.
* Added support for non-published condition variables. One has to call
Init() on those, and add entries directly with the
ConditionVariable::Add() method.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25110 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6cef245e 22-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Detemplatized ConditionVariable{Entry}. Merged them with their
respective Private* base class.
* Changed sigwait() and sigsuspend() to use thread_block() instead of a
condition variable.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25100 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b95f6d47 22-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Introduced a set of functions (thread_prepare_to_block(),
thread_block(), thread_unblock(),...) that allow a thread to wait for
something without needing a semaphore or condition variable. It can
simply block and another thread can unblock it. Supports timeouts and
interrupting. Both semaphores and condition variables use this
common mechanism, now.
* Semaphores:
- Some simplifications due to the thread blocking mechanism.
- Changed locking order to sem -> thread. It was the other way around
before and when introducing the wait_for_objects() support I had
also introduced a situation where the locking was reverse, which
could potentially cause a dead lock on SMP systems.
- Instead of queueing thread structures, a semaphore queues
queued_thread entries now, which are created on the stack. The
thread::sem structure could thus be removed.
- Added sem_entry::net_count, which is sem_entry::count plus the
acquisition count of all waiting threads. This number is needed in
remove_thread_from_sem() and instead of computing it there we
maintain it.
- Fixed remove_thread_from_sem(). It would not unblock threads, if
the sem count was <= 0.
- Made sem::last_acquirer unconditional. It is actually needed for
sem_info::latest_holder. Fixed fill_sem_info() accordingly.
- Added some optional tracing output, though only via ktrace_printf().
* Condition variables:
- Could be simplified significantly through the use of the thread
blocking mechanism. Removed a good deal of unnecessary code.
- Moved the ConditionVariableEntry "flags" parameter from Wait() to
Add(), and adjusted all places where condition variables are used
accordingly.
* snooze() uses thread_block_with_timeout() instead of a semaphore.
* Simplified thread interrupting in the signal and user debugger code.
Instead of separate functions for threads waiting on a semaphore or
condititon variable, we only have a single thread_interrupt(), now.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25099 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8db2e374 20-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Removed the feature that a thread can wait for more than one condition
variable at once. It wasn't used anymore, and the code gets simpler.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25080 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 23b95b11 22-Feb-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

We have to remove the thread's condition variable entries when
interrupted early, i.e. when signals were already pending when we
started waiting. Fixes #1832.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24063 a95241bf-73f2-0310-859d-f6bbb57e9c96


# fe19cba8 17-Feb-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

axeld + bonefish:
Before starting to wait on a condition variable check for pending
signals first, if the call is interruptable.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23980 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6761f5a6 25-Jan-2008 Michael Lotz <mmlr@mlotz.ch>

Move the handling of still running threads into scheduler_enqueue_in_run_queue().
This should be in line with all uses of scheduler_enqueue_in_run_queue() and
simplifies a few places where it is used.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23738 a95241bf-73f2-0310-859d-f6bbb57e9c96


# bd0689e6 17-Jan-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Added usage message to "cvar" and "cvars" debugger commands and define
temporary variables.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23596 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8609f5a2 01-Oct-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

* Increased condition variable hash size.
* Renamed condition variable debugger commands to cvar and cvars.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22402 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d0c2af77 01-Oct-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Addressed a deadlock race condition: Acquiration of condition variable
and thread spinlock was reverse in Wait() and Notify(). The thread lock
is now the outer lock -- this way it is still possible to call Notify()
with the thread lock being held.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22401 a95241bf-73f2-0310-859d-f6bbb57e9c96


# addece20 02-Sep-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

* Fixed incorrect check in condition_variable_interrupt_thread().
Condition variables would never be interrupted.
* ConditionVariableEntry::Add() did not correctly insert the entry into
the per-thread list of entries (the next link of the previous entry
was not adjusted), which could leave the entry unnotified when the
previous entry was notified, thus leaving it in the respective
condition variable's list after the end of its life time. This should
fix a crashing bug I rarely encountered.
* Added debug checks in the PrivateConditionVariableEntry
constructor/destructor that should have helped me to find
forementioned bug hours earlier, had I been bright enough to realize
that I didn't include <debug.h> and those KDEBUG guarded checks were
never executed. :-/


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22151 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 63fa790e 27-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

fVariable was not correctly unset when the condition variable entry was
removed from the variable, which could lead to crashes under certain
cicrumstances.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22090 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c9e5503e 27-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Notify*() and Unpublish() acquire the threads lock. So they need to know
whether the lock is already being held.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22087 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4ed79176 27-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Wait() returns a status_t now, which can be B_OK (condition variable
exists and thread was notified), B_ENTRY_NOT_FOUND (condition variable
not found or Unpublish()ed while waiting), or B_INTERRUPTED
(interrupted by a signal).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22083 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ff308b0b 26-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Condition variables changes:
* Removed left-over commented C implementation.
* It is now possible for a thread to wait for more than one condition
variable at a time.
* Made waiting for condition variables optionally interruptable.
* Renamed Notify() method to NotifyAll() and added a NotifyOne(), so
that it is now possible to wake up only one of the waiting threads.
Pretty much untested at the moment.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22081 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 227402f2 09-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Added simple condition variables to the kernel. They are a relatively
cheap means to block threads until notified explicitely.
threads


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21874 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 03fb2d886830e4dd4b344c56725db59f96733216 07-Nov-2013 Pawel Dziepak <pdziepak@quarnos.org>

kernel: Remove gSchedulerLock

* Thread::scheduler_lock protects thread state, priority, etc.
* sThreadCreationLock protects thread creation and removal and list of
threads in team.
* Team::signal_lock and Team::time_lock protect list of threads in team
as well.
* Scheduler uses its own internal locking.


# 11cacd0c1345cd3296f12e07d18996a2c7572a64 04-Nov-2013 Pawel Dziepak <pdziepak@quarnos.org>

kernel: Remove thread_block_with_timeout_locked()


# 0e88a887b4a9ecaaf1062078d9ca9bfca78fcf3a 13-Jun-2012 Alex Smith <alex@alex-smith.me.uk>

First round of 64-bit safety fixes in the kernel.

* Most of this is incorrect printf format strings. Changed all strings
causing errors to use the B_PRI* format string definitions, which
means the strings should be correct across all platforms.
* Some other fixes for errors, casts required, etc.


# 24df65921befcd0ad0c5c7866118f922da61cb96 11-Jun-2011 Ingo Weinhold <ingo_weinhold@gmx.de>

Merged signals-merge branch into trunk with the following changes:
* Reorganized the kernel locking related to threads and teams.
* We now discriminate correctly between process and thread signals. Signal
handlers have been moved to teams. Fixes #5679.
* Implemented real-time signal support, including signal queuing, SA_SIGINFO
support, sigqueue(), sigwaitinfo(), sigtimedwait(), waitid(), and the addition
of the real-time signal range. Closes #1935 and #2695.
* Gave SIGBUS a separate signal number. Fixes #6704.
* Implemented <time.h> clock and timer support, and fixed/completed alarm() and
[set]itimer(). Closes #5682.
* Implemented support for thread cancellation. Closes #5686.
* Moved send_signal() from <signal.h> to <OS.h>. Fixes #7554.
* Lots over smaller more or less related changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42116 a95241bf-73f2-0310-859d-f6bbb57e9c96


# af983c175d62713b0598366f2fc365ba56d46b26 03-Dec-2009 Colin Günther <coling@gmx.de>

Coding style cleanups. Thanks axeld.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34462 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1581b764e0a14e86671bc5193516eedc621610e9 02-Dec-2009 Colin Günther <coling@gmx.de>

* Adding static Notify{One,All} functions. This allows a cleaner implementation
of the condition variable and synchronization subsystem of the freebsd compat
layer which will be committed next.
* Also there was a discussion about adding these functions on the commit
mailing list. The mail in http://www.freelists.org/post/haiku-commits/r34395-in-haikutrunksrclibscompatfreebsd-network-compatsys,3
is a good sum up of it (need to scroll somewhat down, though).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34458 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5ee1f125e59267d8dce4c22c7d030d0310eebbf3 21-Oct-2009 Michael Lotz <mmlr@mlotz.ch>

Make use of the wait status field so it can be provided in Notify() and then
read out in the ConditionVariableEntry::WaitStatus(). That way you can notify
with a specific status that can be read out on the other end.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33718 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5147963dcd57fefa4f63c484eb88e9eaf4002976 26-Jul-2009 Stephan Aßmus <superstippi@gmx.de>

headers/private/kernel/util/OpenHashTable.h, Hugo's version, is a bit nicer than
Tracker's OpenHashTable.h which it should eventually replace. We've renamed the
class to BOpenHashTable and changed the interface slightly so that HashTableLink
became superfluous.
Adapted all the code that used it. Since the OpenHashTables no longer clash,
this should fix the GCC4 build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31791 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 227fe7d34aeed45d0727a0abde2ea2309352983b 23-Apr-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

* Scheduler/wait object listener:
- Moved scheduler listening interface to <listeners.h> and added more
convenient to use templatized notification functions.
- Added a listener mechanism for the wait objects (semaphores, condition
variables, mutex, rw_lock).
* system profiler:
- Hopefully fixed locking issues related to notifying the profiler thread
for good. We still had an inconsistent locking order, since the scheduler
notification callbacks are invoked with the thread lock held and have to
acquire the object lock then, while the other callbacks acquired the object
lock first and as a side effect of ConditionVariable::NotifyOne() acquired
the thread lock. Now we make sure the object lock is the innermost lock.
- Track the number of dropped events due to a full buffer.
_user_system_profiler_next_buffer() returns this count now.
- When scheduling profiling events are requested also listen to wait objects
and generate the respective profiling events. We send those events lazily
and cache the infos to avoid resending an event for the same wait object.
- When starting profiling we do now generate "thread scheduled" events for
the already running threads.
- _user_system_profiler_start(): Check whether the parameters pointer is a
userland address at all.
- The system_profiler_team_added event does now also contain the team's name.
* Added a sem_get_name_unsafe() returning a semaphore's name. It is "unsafe",
since the caller has to ensure that the semaphore exists and continues to
exist as long as the returned name is used.
* Adjusted the "profile" and "scheduling_recorder" according to the system
profiling changes. The latter prints the number of dropped events, now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30345 a95241bf-73f2-0310-859d-f6bbb57e9c96


# fd0803f3003a667986c914254b4735254cb4db4e 06-Apr-2009 Axel Dörfler <axeld@pinc-software.de>

* Added RemoveTail() method.
* Renamed DoublyLinkedList::Size() to Count(), since it actually counts the
items (ie. O(n)).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29979 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 020ac568404b8ab78825622d8815be48e987f649 03-Sep-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Fixed bug in the "scheduler" command: The check when a thread was
unscheduled was incorrect.
* Introduced _kern_analyze_scheduling() syscall. It requires scheduler
kernel tracing to be enabled. It uses the tracing entries for a given
period of time to do a similar analysis the "scheduler" debugger
command does (i.e. number of runs, run time, latencies, preemption
times) for each thread. Additionally the analysis includes for each
thread how long the thread waited on each locking primitive in total.
* Added kernel tracing for the creation of semaphores and initialization
of condition variables, mutexes, and rw locks. The enabling macro is
SCHEDULING_ANALYSIS_TRACING. The only purpose is to provide
_kern_analyze_scheduling() with more info on the locking primitives
(the name in particular).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27304 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 1a617f516a3a06b29c362acfec4142d31c17b46f 03-Aug-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

More informative panic().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26773 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 15374c5dbdb2c6b700bb2191887cadad7ef9eb73 02-Aug-2008 Axel Dörfler <axeld@pinc-software.de>

* Renamed thread_spinlock and team_spinlock to gThreadSpinlock and
gTeamSpinlock.
* Renamed the static global variables in smp.c to match our style guide.
* Minor other cleanup.
* Removed superfluous white space.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26730 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8cc3c74406b4b4c4b687fa85f6a5c56989743a56 28-Jul-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

The "cvar" command wasn't happy with private condition variables. Now we
don't check any longer whether the given number is the address of a
condition variable in the global hash table; we just assume it is a
valid condition variable pointer.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26674 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 5c99d639708df9b4e2cc847b38d510149d19ec78 22-Jul-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Merged branch haiku/branches/developer/bonefish/vm into trunk. This
introduces the following relevant changes:
* VMCache:
- Renamed vm_cache to VMCache, merged it with vm_store and made it a
C++ class with virtual methods (replacing the store operations).
Turned the different store implementations into subclasses.
- Introduced MergeStore() callback, changed semantics of Commit().
- Changed locking and referencing semantics. A reference can only be
acquired/released with the cache locked. An unreferenced cache is
deleted and a mergeable cache merged when it is unlocked. This
removes the "busy" state of a cache and simplifies the page fault
code.
* Added VMAnonymousCache, which will implement swap support (work by
Zhao Shuai). It is not integrated and used yet, though.
* Enabled the mutex/recursive lock holder asserts.
* Fixed DoublyLinkedList::Swap().
* Generalized the low memory handler to a low resource handler. And made
semaphores and reserved memory handled resources. Made
vm_try_resource_memory() optionally wait (with timeout), and used that
feature to reserve memory for areas.
...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26572 a95241bf-73f2-0310-859d-f6bbb57e9c96


# cb9191556c39d4321b6dc700532eb74f598d166d 16-Jul-2008 Axel Dörfler <axeld@pinc-software.de>

bonefish + axeld:
* Removed the superfluous "flags" parameter from ConditionVariable::Add()
that we forgot there when we moved the flags field from
ConditionVariableEntry::Add() to Wait().
* Using this method was therefore not a good idea - only UnixFifo did, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26454 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 276aa463efb0cc5b6562c46b540c01df679f77ba 24-Jun-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Replaced the useless InitCheck() method in {Open,Multi}HashTable (it
always returned B_OK) by a Init() method, which sets the initial size
and returns an error, if that fails.
* Adjusted code using the classes accordingly. Replaced a few
InitCheck() methods in the network code by Init().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26127 a95241bf-73f2-0310-859d-f6bbb57e9c96


# fbe0c27a94fff9dff7c42e12ee96f789b314c746 17-May-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

axeld + bonefish:
Changed condition variables so that it is allowed to block (e.g. lock
mutexes etc.) between Add() and Wait(). This fixes #2059, since the
block writer used them this way and could thusly fail to wait for a
condition variable, causing a temporary stack object to be used past its
lifetime.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25525 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 023bf5fcda8c37eb8e295784608ce818384a0ca5 22-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added support for timeouts.
* Added support for non-published condition variables. One has to call
Init() on those, and add entries directly with the
ConditionVariable::Add() method.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25110 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6cef245eca821584f07f5a13558f51ec586852e8 22-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Detemplatized ConditionVariable{Entry}. Merged them with their
respective Private* base class.
* Changed sigwait() and sigsuspend() to use thread_block() instead of a
condition variable.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25100 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b95f6d4710855a27bec41b6fae2b064347780173 22-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Introduced a set of functions (thread_prepare_to_block(),
thread_block(), thread_unblock(),...) that allow a thread to wait for
something without needing a semaphore or condition variable. It can
simply block and another thread can unblock it. Supports timeouts and
interrupting. Both semaphores and condition variables use this
common mechanism, now.
* Semaphores:
- Some simplifications due to the thread blocking mechanism.
- Changed locking order to sem -> thread. It was the other way around
before and when introducing the wait_for_objects() support I had
also introduced a situation where the locking was reverse, which
could potentially cause a dead lock on SMP systems.
- Instead of queueing thread structures, a semaphore queues
queued_thread entries now, which are created on the stack. The
thread::sem structure could thus be removed.
- Added sem_entry::net_count, which is sem_entry::count plus the
acquisition count of all waiting threads. This number is needed in
remove_thread_from_sem() and instead of computing it there we
maintain it.
- Fixed remove_thread_from_sem(). It would not unblock threads, if
the sem count was <= 0.
- Made sem::last_acquirer unconditional. It is actually needed for
sem_info::latest_holder. Fixed fill_sem_info() accordingly.
- Added some optional tracing output, though only via ktrace_printf().
* Condition variables:
- Could be simplified significantly through the use of the thread
blocking mechanism. Removed a good deal of unnecessary code.
- Moved the ConditionVariableEntry "flags" parameter from Wait() to
Add(), and adjusted all places where condition variables are used
accordingly.
* snooze() uses thread_block_with_timeout() instead of a semaphore.
* Simplified thread interrupting in the signal and user debugger code.
Instead of separate functions for threads waiting on a semaphore or
condititon variable, we only have a single thread_interrupt(), now.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25099 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8db2e374929b7ac0cf11a064c93fefff5926588d 20-Apr-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Removed the feature that a thread can wait for more than one condition
variable at once. It wasn't used anymore, and the code gets simpler.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25080 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 23b95b112db936067bdf4188974680b562099587 22-Feb-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

We have to remove the thread's condition variable entries when
interrupted early, i.e. when signals were already pending when we
started waiting. Fixes #1832.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24063 a95241bf-73f2-0310-859d-f6bbb57e9c96


# fe19cba8f06ac099d9731551380ef372bc96ae9a 17-Feb-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

axeld + bonefish:
Before starting to wait on a condition variable check for pending
signals first, if the call is interruptable.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23980 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6761f5a660bcba247e0967e09ac58f2f4488bd55 25-Jan-2008 Michael Lotz <mmlr@mlotz.ch>

Move the handling of still running threads into scheduler_enqueue_in_run_queue().
This should be in line with all uses of scheduler_enqueue_in_run_queue() and
simplifies a few places where it is used.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23738 a95241bf-73f2-0310-859d-f6bbb57e9c96


# bd0689e66829b9e05545c831cc817ba069224acc 17-Jan-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

Added usage message to "cvar" and "cvars" debugger commands and define
temporary variables.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23596 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8609f5a242bff1992094f81f7ac71ca3b67c13c4 01-Oct-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

* Increased condition variable hash size.
* Renamed condition variable debugger commands to cvar and cvars.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22402 a95241bf-73f2-0310-859d-f6bbb57e9c96


# d0c2af771393d353dde1f0375d1edbf1f410be50 01-Oct-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Addressed a deadlock race condition: Acquiration of condition variable
and thread spinlock was reverse in Wait() and Notify(). The thread lock
is now the outer lock -- this way it is still possible to call Notify()
with the thread lock being held.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22401 a95241bf-73f2-0310-859d-f6bbb57e9c96


# addece2001c2683709aec70ec48f91fa142c0752 02-Sep-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

* Fixed incorrect check in condition_variable_interrupt_thread().
Condition variables would never be interrupted.
* ConditionVariableEntry::Add() did not correctly insert the entry into
the per-thread list of entries (the next link of the previous entry
was not adjusted), which could leave the entry unnotified when the
previous entry was notified, thus leaving it in the respective
condition variable's list after the end of its life time. This should
fix a crashing bug I rarely encountered.
* Added debug checks in the PrivateConditionVariableEntry
constructor/destructor that should have helped me to find
forementioned bug hours earlier, had I been bright enough to realize
that I didn't include <debug.h> and those KDEBUG guarded checks were
never executed. :-/


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22151 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 63fa790e9b62cf0863a530d305a57d077ace72d8 27-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

fVariable was not correctly unset when the condition variable entry was
removed from the variable, which could lead to crashes under certain
cicrumstances.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22090 a95241bf-73f2-0310-859d-f6bbb57e9c96


# c9e5503e5e2490c4e7e9e0caa80fcc47a1c6f4df 27-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Notify*() and Unpublish() acquire the threads lock. So they need to know
whether the lock is already being held.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22087 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 4ed7917682c43a005d86857889895a63374b66ea 27-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Wait() returns a status_t now, which can be B_OK (condition variable
exists and thread was notified), B_ENTRY_NOT_FOUND (condition variable
not found or Unpublish()ed while waiting), or B_INTERRUPTED
(interrupted by a signal).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22083 a95241bf-73f2-0310-859d-f6bbb57e9c96


# ff308b0b491531f2f3b5d22244d7ac5904133e61 26-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Condition variables changes:
* Removed left-over commented C implementation.
* It is now possible for a thread to wait for more than one condition
variable at a time.
* Made waiting for condition variables optionally interruptable.
* Renamed Notify() method to NotifyAll() and added a NotifyOne(), so
that it is now possible to wake up only one of the waiting threads.
Pretty much untested at the moment.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22081 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 227402f2bfd4187053a07abd674464cf88885a3d 09-Aug-2007 Ingo Weinhold <ingo_weinhold@gmx.de>

Added simple condition variables to the kernel. They are a relatively
cheap means to block threads until notified explicitely.
threads


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21874 a95241bf-73f2-0310-859d-f6bbb57e9c96