Searched +hist:1 +hist:bc7045f (Results 1 - 25 of 29) sorted by relevance

12

/haiku/headers/private/kernel/arch/
H A Dsystem_info.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/system/libroot/os/
H A Dsystem_info.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DJamfilediff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff b0944c78 Thu Aug 01 00:51:16 MDT 2013 Ingo Weinhold <ingo_weinhold@gmx.de> More work towards hybrid support

* All packaging architecture dependent variables do now have a
respective suffix and are set up for each configured packaging
architecture, save for the kernel and boot loader variables, which
are still only set up for the primary architecture.
For convenience TARGET_PACKAGING_ARCH, TARGET_ARCH, TARGET_LIBSUPC++,
and TARGET_LIBSTDC++ are set to the respective values for the primary
packaging architecture by default.
* Introduce a set of MultiArch* rules to help with building targets for
multiple packaging architectures. Generally the respective targets are
(additionally) gristed with the packaging architecture. For libraries
the additional grist is usually omitted for the primary architecture
(e.g. libroot.so and <x86>libroot.so for x86_gcc2/x86 hybrid), so that
Jamfiles for targets built only for the primary architecture don't
need to be changed.
* Add multi-arch build support for all targets needed for the stage 1
cross devel package as well as for libbe (untested).
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff b0944c78b074a8110bd98e060415d0e8f38a7f65 Thu Aug 01 00:51:16 MDT 2013 Ingo Weinhold <ingo_weinhold@gmx.de> More work towards hybrid support

* All packaging architecture dependent variables do now have a
respective suffix and are set up for each configured packaging
architecture, save for the kernel and boot loader variables, which
are still only set up for the primary architecture.
For convenience TARGET_PACKAGING_ARCH, TARGET_ARCH, TARGET_LIBSUPC++,
and TARGET_LIBSTDC++ are set to the respective values for the primary
packaging architecture by default.
* Introduce a set of MultiArch* rules to help with building targets for
multiple packaging architectures. Generally the respective targets are
(additionally) gristed with the packaging architecture. For libraries
the additional grist is usually omitted for the primary architecture
(e.g. libroot.so and <x86>libroot.so for x86_gcc2/x86 hybrid), so that
Jamfiles for targets built only for the primary architecture don't
need to be changed.
* Add multi-arch build support for all targets needed for the stage 1
cross devel package as well as for libbe (untested).
/haiku/src/bin/
H A Dsysinfo.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1f5facdb Sat Apr 28 01:59:52 MDT 2012 Jerome Duval <jerome.duval@gmail.com> sysinfo: switch to c++
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
1f5facdbe7e25dc9618ec413eda01adf82d763f2 Sat Apr 28 01:59:52 MDT 2012 Jerome Duval <jerome.duval@gmail.com> sysinfo: switch to c++
/haiku/src/apps/pulse/
H A DPulseApp.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DPulseView.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DDeskbarPulseView.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DPulseApp.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DNormalPulseView.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/processcontroller/
H A DMemoryBarMenu.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DProcessController.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DTeamBarMenuItem.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DMemoryBarMenu.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1c292f7e Fri Jul 19 18:50:36 MDT 2013 Rene Gollent <anevilyak@gmail.com> ProcessController: Fix memory calculations.

On systems with > 4GB of memory, the calculations would overflow,
leading to the memory bars being drawn incorrectly.
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1c292f7eb4e1aaebdb8ea3d860ffb1f4963821ba Fri Jul 19 18:50:36 MDT 2013 Rene Gollent <anevilyak@gmail.com> ProcessController: Fix memory calculations.

On systems with > 4GB of memory, the calculations would overflow,
leading to the memory bars being drawn incorrectly.
H A DProcessController.cppdiff c2e78713 Wed Jan 13 05:00:51 MST 2021 Adrien Destugues <adrien.destugues@opensource.viveris.fr> ProcessController: reintroduce the static scaling mode.

There is a very good reason to have this: for low number of cores, the
default computation makes stupidly large bars.

I had tested my changes with various number of cores (1, 2, 3, 4, 8, 16)
in QEMU to make sure it looked correct in all cases. I don't understand
why kallisti5 reintroduced broken code.

This reverts commit b18298348af33f990b51d66cf21652b0a4520317.
This reverts commit b1b6769b6f040f077544d7884ca5a7c4fbb7af27.
diff b1829834 Sun Jan 10 18:06:31 MST 2021 Alexander von Gluck IV <kallisti5@unixzen.com> ProcessController: Just toss static scaling mode all together

* It was making things confusing and honestly the dynamic
calculation code does a pretty good job.
* Just make sure we scale the scale the CPU bars with a
multipler that makes sense for a minimum width.
* This should give us a good baseline. Tested 1 to 32 cpus

Change-Id: If41c73e68b2de2b39196013af13e6c0ffdbe6489
diff b1b6769b Sun Jan 10 16:53:08 MST 2021 Alexander von Gluck IV <kallisti5@unixzen.com> ProcessController: Fix static scaling mode after hrev54874

* We saw a "big" cpu bar on 1 core.
* This was because adding 8 to the static "15" width
resulted in the static CPU sizing code getting disabled
* Converting this to 4 just completely disabled the static
scaling code and made dynamic always enabled

Change-Id: Ida8c718c0d0a2fcf72aedbf525daad040d5b3678
diff c38dea9e Fri Jan 08 23:48:46 MST 2021 Alexander von Gluck IV <kallisti5@unixzen.com> processcontroller: Scale up width on high core counts

* 4 cores or less, use static table. More make view larger.
* 16 cores or less, 2px CPU bars
* More than 16 cores, 1px CPU bars
* Tested through 128 cores in qemu

Change-Id: I5fb460e7ee5848d0395b109acc602e86f4d5bbd7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3616
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1c292f7e Fri Jul 19 18:50:36 MDT 2013 Rene Gollent <anevilyak@gmail.com> ProcessController: Fix memory calculations.

On systems with > 4GB of memory, the calculations would overflow,
leading to the memory bars being drawn incorrectly.
diff 3440db0c Sat Feb 19 06:32:39 MST 2011 Siarzhuk Zharski <zharik@gmx.li> Yet another localization patch made by Jorma Karvonen.
Fixes #7238

Notes on patch:
1) Localization of internal Deskbar item name and kClassName rejected;

Additional fixes by S.Zharski:
1) BLocker's internal name localization removed;
2) A bit more safe snprintf used instead of sprintf;
3) Localization of field names in 'PrTh' message removed;
4) Localization of calling "db" debugger removed. The thread debugging command
"db %d" replaced with "gdb -pid=%d".



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40558 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 3440db0c Sat Feb 19 06:32:39 MST 2011 Siarzhuk Zharski <zharik@gmx.li> Yet another localization patch made by Jorma Karvonen.
Fixes #7238

Notes on patch:
1) Localization of internal Deskbar item name and kClassName rejected;

Additional fixes by S.Zharski:
1) BLocker's internal name localization removed;
2) A bit more safe snprintf used instead of sprintf;
3) Localization of field names in 'PrTh' message removed;
4) Localization of calling "db" debugger removed. The thread debugging command
"db %d" replaced with "gdb -pid=%d".



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40558 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1d1b0d06 Fri Aug 31 18:31:19 MDT 2007 Ingo Weinhold <ingo_weinhold@gmx.de> Made ProcessController's "Debug Thread" feature work under Haiku. We
don't have a "db" command (we could probably add a small shell script
that invokes gdb in a Terminal), but just as BeOS we have
debug_thread(), which does exactly that -- throwing a thread into the
debugger. It (at least Haiku's version, not sure about BeOS's) also
interrupts system calls, which makes the semaphore releasing hack
superfluous.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22132 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/headers/private/system/
H A Dsystem_info.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A Dsyscalls.hdiff f66d2b46 Wed Jul 26 14:51:38 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> kernel: Add event queue implementation to wait for objects efficiently.

Based on hamishm's original patch from 2015, but heavily modified,
refactored, and reworked.

From the original commit message:

> When an object is deleted, a B_EVENT_INVALID event is delivered,
> and the object is unregistered from the queue.
>
> The special event flag B_EVENT_ONE_SHOT can be passed in when adding
> an object so that the object is automatically unregistered when an
> event is delivered.

Modifications to the original change include:

* Removed the public interface (syscalls remain private for the moment)

* Event list queueing/dequeueing almost entirely rewritten, including:
- Clear events field when dequeueing.

- Have B_EVENT_QUEUED actually indicate whether the event has been
appended to the linked list (or not), based around lock state.
The previous logic was prone to races and double-insertions.

- "Modify" is now just "Deselect + Select" performed at once;
previously it could cause use-after-frees.

- Unlock for deselect only once at the end of dequeue.

- Handle INVALID events still in the queue upon destruction,
fixing memory leaks.

* Deduplified code with wait_for_objects.

* Use of C++ virtual dispatch instead of C-style enum + function calls,
and BReferenceable plus destructors for teardown.

* Removed select/modify/delete flags. Select/Modify are now the same
operation on the syscall interface, and "Delete" is done when 0
is passed for "events". Additionally, the events selected can be fetched
by passing -1 for "events".

* Implemented level-triggered mode.

* Use of BStackOrHeapArray and other convenience routines in syscalls.

Change-Id: I1d2f094fd981c95215a59adbc087523c7bbbe40b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6745
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
diff 6f3f29c7 Tue Jun 06 21:30:15 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> user_mutex: Refactor locking and unblocking mechanism.

Suppose the following scenario:

1. Thread A holds a mutex.

2. Thread B goes to acquire the mutex, winds up in kernel waiting.

3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)

4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.

5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.

6. Thread A, suspended back in step 3, resumes.

Now we encounter the problem. Under the previous code, the following
would occur.

7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!

8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!

The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.

Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.

That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.

Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.

Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.

Fixes #18436.

Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 6f3f29c7 Tue Jun 06 21:30:15 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> user_mutex: Refactor locking and unblocking mechanism.

Suppose the following scenario:

1. Thread A holds a mutex.

2. Thread B goes to acquire the mutex, winds up in kernel waiting.

3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)

4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.

5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.

6. Thread A, suspended back in step 3, resumes.

Now we encounter the problem. Under the previous code, the following
would occur.

7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!

8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!

The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.

Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.

That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.

Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.

Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.

Fixes #18436.

Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 6f3f29c7 Tue Jun 06 21:30:15 MDT 2023 Augustin Cavalier <waddlesplash@gmail.com> user_mutex: Refactor locking and unblocking mechanism.

Suppose the following scenario:

1. Thread A holds a mutex.

2. Thread B goes to acquire the mutex, winds up in kernel waiting.

3. Thread A unlocks; first unsets the LOCKED flag.
As WAITING is set, it calls the kernel; but instead of processing
this immediately, the thread is suspended for any reason (locks,
reschedule, etc.)

4. Thread B hits a timeout, or a signal. It then unblocks in the kernel,
which causes the WAITING flag to be unset.

5. Thread C goes to acquire the lock. It sets the LOCKED flag.
It sees the WAITING flag is not set, so it returns at once,
having successfully acquired the lock.

6. Thread A, suspended back in step 3, resumes.

Now we encounter the problem. Under the previous code, the following
would occur.

7. Thread A sees that no threads are waiting. It thus unsets the LOCKED
flag, and returns from the kernel. Now we have a mutex theoretically
held by thread C but which (illegally) has no LOCKED flag set!

8. Some other thread tries to acquire the lock, and succeeds, for LOCKED
is not set. We now have one lock owned by two separate threads.
That's very bad!

The solution, in this commit, is to (1) switch from using "atomic_or"
to lock mutexes, to using "atomic_test_and_set", and (2) mandate that
_kern_unblock_mutex must be invoked with the mutex already unlocked.

Trying to solve the problem with (2) but without (1) produces other
complications and would overall be more complicated. For instance,
all existing userland code expected that it would set LOCKED, but then
check LOCKED|WAITING. If _kern_mutex_unlock does not unset LOCKED,
then whichever thread sets LOCKED when it was previously unset is
now the mutex's undisputed owner, and if it fails to notice this,
would deadlock.

That could have been solved with extra checks at all lock points, but
then that would mean locks would not be acquired "fairly": it would
be possible for any thread to race with an unlocking thread, and
acquire the lock before the kernel had a chance to wake anyone up.

Given how fast atomics can be, and how slow invoking the kernel is
comparatively, that would probably make our mutexes extremely "unfair."
This would not violate the POSIX specification, but it does seem like
a dangerous choice to make in implementing these APIs.

Linux's "futex" API, which our API bears some similarities to, requires
at least one atomic test-and-set for an uncontended acquisition,
and multiple atomics more for even the simplest case of contended
acquisition. If it works for them, it should work for us, too.

Fixes #18436.

Change-Id: Ib8c28acf04ce03234fe738e41aa0969ca1917540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6537
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/system/kernel/arch/x86/
H A Darch_system_info.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/kits/tracker/
H A DTaskLoop.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/activitymonitor/
H A DSystemInfo.hdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
H A DDataSource.cppdiff 1f5daef0 Tue Feb 27 15:06:15 MST 2024 Emir SARI <bitigchi@me.com> ActivityMonitor: use BNumberFormat for i18n

Change-Id: I3179f84cbaee25624c2f4a7b092a28b5281a5f16
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7480
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1cac1beb Sat Jul 13 11:32:55 MDT 2013 Philippe Saint-Pierre <stpere@gmail.com> ActivityMonitor: use new units KiB/MiB for display (#5378)
diff b190a54c Thu Nov 22 06:20:57 MST 2012 Ithamar R. Adema <ithamar@upgrade-android.com> activitymonitor: remove B_MAX_CPU_COUNT reference

It has no use, since we don't know its value and the list of colors
might be longer (for example, for ARM currently B_MAX_CPU_COUNT is
only 1). The modula operator later on makes sure we keep within the
bounds of the kColors array anyway.
diff ee872034 Sun Nov 14 04:29:50 MST 2010 Axel Dörfler <axeld@pinc-software.de> * Start numbering the CPUs with 1 instead of 0. This closes ticket #6816.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39426 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1cac1bebcb957e4f7edea51b1de1976a4ec37bc6 Sat Jul 13 11:32:55 MDT 2013 Philippe Saint-Pierre <stpere@gmail.com> ActivityMonitor: use new units KiB/MiB for display (#5378)
diff b190a54c4046dd230f5ae19ad4fa86cf3d1dc4fc Thu Nov 22 06:20:57 MST 2012 Ithamar R. Adema <ithamar@upgrade-android.com> activitymonitor: remove B_MAX_CPU_COUNT reference

It has no use, since we don't know its value and the list of colors
might be longer (for example, for ARM currently B_MAX_CPU_COUNT is
only 1). The modula operator later on makes sure we keep within the
bounds of the kColors array anyway.
diff ee87203426eeaa36e41a8f33d417388ae32543ca Sun Nov 14 04:29:50 MST 2010 Axel Dörfler <axeld@pinc-software.de> * Start numbering the CPUs with 1 instead of 0. This closes ticket #6816.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39426 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/libroot/posix/sys/
H A Duname.cdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/packageinstaller/
H A DPackageInfo.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/apps/diskprobe/
H A DTypeEditors.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
/haiku/src/system/kernel/
H A Dsystem_info.cppdiff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1d578e15 Wed Jun 02 14:46:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Fixed more address types related issues. Mostly printf() or comparison
warnings, but also some oversights from earlier changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37000 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1d578e15fe5b5c3ff62866ae81aef529d00d7762 Wed Jun 02 14:46:49 MDT 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Fixed more address types related issues. Mostly printf() or comparison
warnings, but also some oversights from earlier changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37000 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/headers/private/shared/
H A Dcpu_type.hdiff 8a9e1e0d Sun Dec 31 14:10:55 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> Removal of non-Haiku target platform logic from build system (part 1.)

Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.

This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1bc7045f Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1e8adb7d Thu Aug 24 04:33:50 MDT 2006 Jérôme Duval <korli@users.berlios.de> added core and core 2 ids


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18603 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 1bc7045fdfb85e6151d01c73669be19627c4783b Sun Dec 15 19:58:43 MST 2013 Pawel Dziepak <pdziepak@quarnos.org> kernel, libroot: Introduce new API for obtaining system info
diff 1e8adb7d892e8082415b3d0d632831896a6b4210 Thu Aug 24 04:33:50 MDT 2006 Jérôme Duval <korli@users.berlios.de> added core and core 2 ids


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

Completed in 547 milliseconds

12