starred/ppsspp

Fork 0

mirror of https://github.com/hrydgard/ppsspp.git synced 2026-04-24 21:56:10 +03:00

[GH-ISSUE #18] Mutex and LwMutex not correctly implemented #8

New issue

Closed

opened 2026-03-17 03:02:07 +03:00 by kerem · 7 comments

kerem commented

2026-03-17 03:02:07 +03:00

Owner

Originally created by @hrydgard on GitHub (Nov 6, 2012).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/18

Originally created by @hrydgard on GitHub (Nov 6, 2012). Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/18

kerem closed this issue

2026-03-17 03:02:12 +03:00

kerem commented

2026-03-17 03:02:18 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Nov 18, 2012):

So far I have mutexes mostly working and tested on my forks, but I've realized I'm not testing a few things which may matter...

Here's my todo list:

Test rescheduling in error scenarios (like invalid id.)
Write some tests for lwmutexes.
Try to implement lwmutexes (at least a draft?)
Figure out the second 16 bytes of the lwmutex workarea.
Maybe figure out what makes sceKernelTryLockLwMutex_600 special.
Add timeout support to waits (updateable.)
Threads can't be re-started on PPSSPP yet, write tests / fix.
Priority attr for mutexes/semaphores not done, but can't be tested right without better threadqueue.

TBH, I don't really know what lwmutexes are though, I assume it means "lightweight"? What I do know:

NativeLwMutex was changed in yaupspe and looks more correct there. (although not sure how to verify it.)
The workarea is 8 dwords, which are cleared on create/delete.
- First four are count, locking thread, attr, and waiting threads.
- 5th appears to be a uid maybe (don't know how to verify.)
- 6/7/8 may be pad, haven't found a way to make them non-zero yet.
JPCSP says lwmutexes can't be used in interrupts.

-[Unknown]

@unknownbrackets commented on GitHub (Nov 18, 2012): So far I have mutexes mostly working and tested on [my](https://github.com/unknownbrackets/ppsspp/tree/mutexes) [forks](https://github.com/unknownbrackets/pspautotests/tree/mutex-tests), but I've realized I'm not testing a few things which may matter... Here's my todo list: - Test rescheduling in error scenarios (like invalid id.) - Write some tests for lwmutexes. - Try to implement lwmutexes (at least a draft?) - Figure out the second 16 bytes of the lwmutex workarea. - Maybe figure out what makes `sceKernelTryLockLwMutex_600` special. - Add timeout support to waits (updateable.) - Threads can't be re-started on PPSSPP yet, write tests / fix. - Priority attr for mutexes/semaphores not done, but can't be tested right without better threadqueue. TBH, I don't really know what lwmutexes are though, I assume it means "lightweight"? What I do know: - `NativeLwMutex` was changed in yaupspe and looks more correct there. (although not sure how to verify it.) - The workarea is 8 dwords, which are cleared on create/delete. - First four are count, locking thread, attr, and waiting threads. - 5th appears to be a uid maybe (don't know how to verify.) - 6/7/8 may be pad, haven't found a way to make them non-zero yet. - JPCSP says lwmutexes can't be used in interrupts. -[Unknown]

kerem commented

2026-03-17 03:02:23 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 18, 2012):

Nice!

About the workareas, I don't think games are very likely to be poking the workarea internals so it probably doesn't matter much exactly how the data inside is organized, as long as all the functions and synchronization behave correctly.

I also think "Lw" means lightweight, although they only appear to be marginally lighter than regular mutexes...

JPCSP has a mechanism where functions can have the attribute "banned in interrupts", we should probably implement that too (can just add an extra flags field to the hlemodule tables).

@hrydgard commented on GitHub (Nov 18, 2012): Nice! About the workareas, I don't think games are very likely to be poking the workarea internals so it probably doesn't matter much exactly how the data inside is organized, as long as all the functions and synchronization behave correctly. I also think "Lw" means lightweight, although they only appear to be marginally lighter than regular mutexes... JPCSP has a mechanism where functions can have the attribute "banned in interrupts", we should probably implement that too (can just add an extra flags field to the hlemodule tables).

kerem commented

2026-03-17 03:02:28 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Nov 18, 2012):

Well, to me they seem less lightweight (require 32 bytes in userspace, still have a uid, at best maybe don't reschedule?) I'm worried access to the workarea (rather than a refer call) could be what makes them more "lightweight" (to use.)

But you're right, JPCSP doesn't preserve it and has reasonable compatibility so it can't matter too much.

-[Unknown]

@unknownbrackets commented on GitHub (Nov 18, 2012): Well, to me they seem less lightweight (require 32 bytes in userspace, still have a uid, at best maybe don't reschedule?) I'm worried access to the workarea (rather than a refer call) could be what makes them more "lightweight" (to use.) But you're right, JPCSP doesn't preserve it and has reasonable compatibility so it can't matter too much. -[Unknown]

kerem commented

2026-03-17 03:02:33 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Nov 19, 2012):

So, I think I implemented timeouts correctly using CoreTiming::ScheduleEvent in 1c20718e3cf2d94620703a9a44bd6db772767f76. I've also added better scheduling testing which is showing more issues.

sceKernelTryLockLwMutex_600 seems to just give better error codes.

Anyway, I noticed a big thing I'd totally forgotten about - threads ending. If a thread locks a mutex, and then ends, the mutex should be unlocked, of course. I can't wait for THREADEND, since I need finer control, and it needs to wakeup threads.

So I was thinking of adding a callback system to listen on threads ending, e.g. just a global std::vector of callbacks (which mutexes and semaphores would listen on, among maybe others?) that would get the thread id on return/exit/terminate. Does that sound right?

-[Unknown]

@unknownbrackets commented on GitHub (Nov 19, 2012): So, I think I implemented timeouts correctly using CoreTiming::ScheduleEvent in 1c20718e3cf2d94620703a9a44bd6db772767f76. I've also added better scheduling testing which is showing more issues. `sceKernelTryLockLwMutex_600` seems to just give better error codes. Anyway, I noticed a big thing I'd totally forgotten about - threads ending. If a thread locks a mutex, and then ends, the mutex should be unlocked, of course. I can't wait for THREADEND, since I need finer control, and it needs to wakeup threads. So I was thinking of adding a callback system to listen on threads ending, e.g. just a global std::vector of callbacks (which mutexes and semaphores would listen on, among maybe others?) that would get the thread id on return/exit/terminate. Does that sound right? -[Unknown]

kerem commented

2026-03-17 03:02:38 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 19, 2012):

Well, at least it doesn't really sound wrong, feel free to give it a shot :)

I wonder if games really do such silly things as locking a mutex and then exitthread, but I guess better safe than sorry..

@hrydgard commented on GitHub (Nov 19, 2012): Well, at least it doesn't really sound wrong, feel free to give it a shot :) I wonder if games really do such silly things as locking a mutex and then exitthread, but I guess better safe than sorry..

kerem commented

2026-03-17 03:02:43 +03:00

Author

Owner

@hrydgard commented on GitHub (Nov 19, 2012):

BTW, nice work on the timeout implementation! Doing it that way looks right.

@hrydgard commented on GitHub (Nov 19, 2012): BTW, nice work on the timeout implementation! Doing it that way looks right.

kerem commented

2026-03-17 03:02:49 +03:00

Author

Owner

@libcg commented on GitHub (Feb 25, 2013):

I'm currently reversing usersystemlib.prx. Here's a source file which could help you in this task :

https://github.com/uofw/uofw/blob/master/src/usersystemlib/kernel_library.c

@libcg commented on GitHub (Feb 25, 2013): I'm currently reversing usersystemlib.prx. Here's a source file which could help you in this task : https://github.com/uofw/uofw/blob/master/src/usersystemlib/kernel_library.c

kerem referenced this issue

2026-03-18 07:26:36 +03:00

[GH-ISSUE #5046] Segmentation fault in Valkyria Chronicles 2 #2117

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ppsspp#8

No description provided.

Rows
Columns