Opened 5 years ago
Closed 19 months ago
#15736 closed bug (fixed)
pthread_barrier_t is not working properly
Reported by: | X512 | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta5 |
Component: | System/POSIX | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev53888.
pthread_barrier_t
is causing freeze on start of OpenGL applications on multicore systems.
Disabling pthread_barrier_t
in Mesa and using Mesa own implementation fixes freeze.
Attachments (1)
Change History (10)
by , 5 years ago
Attachment: | 0001-Haiku-disable-pthread_barrier_t.patch added |
---|
comment:1 by , 5 years ago
Component: | - General → System/POSIX |
---|
comment:3 by , 5 years ago
Do you have a simple testcase that shows the problem? That would be helpful here.
comment:4 by , 5 years ago
I don't identified exact problem yet. To reproduce problem, apply this patch to mesa, enable pthread_barrier_t and run GLTeapot. It will freeze. Freeze appear in render threads.
comment:5 by , 5 years ago
A first step would be attaching a debugger and determining what is waiting and where/why inside libroot's pthread_barrier.cpp.
Actually, looking at that code briefly, I'm not sure why it uses the kernel mutex API directly, rather than using the user_mutex wrappers, seems a little strange. I guess because it needs to do B_USER_MUTEX_UNBLOCK_ALL?
comment:6 by , 5 years ago
Mesa has its own implementation of barrier that can be used as reference: https://github.com/mesa3d/mesa/blob/master/src/util/u_thread.h#L204.
comment:7 by , 5 years ago
Well, there is https://xref.landonf.org/source/xref/haiku/src/tests/system/libroot/posix/pthread_barrier_test.cpp which seems to test the relevant functionality, so I'm not sure what else Mesa could be doing that is causing problems.
comment:9 by , 19 months ago
Milestone: | Unscheduled → R1/beta5 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed in hrev57071.
Mesa patch to disable pthread_barrier_t