Searched +hist:1 +hist:bc7045f (Results 1 - 25 of 29) sorted by relevance
/haiku/headers/private/kernel/arch/ | ||
H A D | system_info.h | 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/libroot/os/ | ||
H A D | system_info.cpp | 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 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 D | Jamfile | 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 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 D | sysinfo.cpp | 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 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 D | PulseApp.h | 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 |
H A D | PulseView.cpp | 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 |
H A D | DeskbarPulseView.cpp | 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 |
H A D | PulseApp.cpp | 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 |
H A D | NormalPulseView.cpp | 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/apps/processcontroller/ | ||
H A D | MemoryBarMenu.h | 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 |
H A D | ProcessController.h | 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 |
H A D | TeamBarMenuItem.cpp | 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 |
H A D | MemoryBarMenu.cpp | 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 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 D | ProcessController.cpp | diff 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 D | system_info.h | 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 |
H A D | syscalls.h | diff 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 D | arch_system_info.cpp | 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/kits/tracker/ | ||
H A D | TaskLoop.cpp | 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/apps/activitymonitor/ | ||
H A D | SystemInfo.h | 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 |
H A D | DataSource.cpp | diff 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 D | uname.c | 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/apps/packageinstaller/ | ||
H A D | PackageInfo.cpp | 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/apps/diskprobe/ | ||
H A D | TypeEditors.cpp | 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/ | ||
H A D | system_info.cpp | 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 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 D | cpu_type.h | diff 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