Mutex and LwMutex not correctly implemented

[hrydgard]

No description provided.

[unknownbrackets]

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]

[hrydgard]

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).

[unknownbrackets]

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]

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]

[hrydgard]

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]

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

[libcg]

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