PTE on PSP OS
All PSP OS objects that are created require a name to be associated with them. The name must be unique among objects that currently exist. To accomplish this, any routines that allocate OS objects (e.g. OsMutexCreate) keep a static local variable that acts as a counter and is incremented every time an object is created. This value is appended to the name of the resource. For instance “mutex04” would be the name of the fourth mutex created.
OsThreadCreate allocates a pspThreadData structure that contains a semaphore used for cancelling a thread, the thread's entry point and parameters to the thread's entry point. A pointer to this structure is stored as a TLS value.
OsThreadCreate calls sceKernelCreateThread with a entry point of pspStubThreadEntry. The stub entry point retrieves the per thread control structure (allocated during OsThreadCreate) and gets the thread's real entry point and parameters and then calls the real entry point.
Unfortunately, PSP OS does not include any kind of thread local storage functionality. To emulate TLS, when a new POSIX thread is created, a structure is allocated to contain TLS keys and values. A pointer to this structure is appended to the thread name. For instance, a new threads name might be “pthread10_80001234”, where 0x80001234 is the address of the TLS structure. When a thread wants to access TLS information, it retrieves the thread's name from the OS, parses the name to extract the pointer and then utilizes the TLS helper library to set or get TLS values.
Unfortunately, this mechanism only works for threads that are created through pthread_create; it does not work for OS threads that are using pthread calls. To emulate this (at this for one thread) we allocate a single TLS structure (like the ones associated with each POSIX thread). This “global” TLS structure is used when pthread is called from a non-POSIX OS thread. This introduces the important limitation that pthread calls can be made from ONLY ONE non-POSIX OS thread. Behavior when calling from multiple different non-POSIX OS threads is undefined.
PSP OS does not supply routines for mutexes. A counting semaphore initialized to 0 is used.
Since PSP OS does not natively provide a way to break out of blocked operations, this functionality is emulated using a cancellation semaphore that is stored in the per thread control data. When the user requests that a thread be cancelled (i.e. OsThreadCancel is called) this semaphore is posted to. In OsSemaphoreCancellablePend, the cancellation semaphore as well as the user semaphore are polled (rather than blocking) and the routine returns if the cancellation semaphore is posted to. A similar technique is used for OsThreadWaitForEnd.