I'm trying to write a small program to demostrate two threads writing to a file. I protect simaltenous writes to the file with a semaphore, but unfortunately I'm get some weird result.
Can anyone tell me if the following is correct
<pre>
void init_Dbug()
{
_writeSema = sceKernelCreateSema("_writeSema", 0, 0, 1, 0);
}
void write_DBug(const char * const text)
{
sceKernelWaitSema(_writeSema, 0, 0);
sceKernelSignalSema(_writeSema, 1);
fprintf(_dBugFile, text);
fflush(_dBugFile);
sceKernelSignalSema(_writeSema, 0);
}
</pre>
Ooutput file, note that 'thread 1' first write is missing, and that the 'newline' character is missing in one case.
<pre>
Thread [2] idx [0]
Thread [1] idx [1]
Thread [2] idx [1]
Thread [1] idx [2]
Thread [2] idx [2]
Thread [1] idx [3]
Thread [2] idx [3]
Thread [1] idx [4]
Thread [2] idx [4]
Thread [1] idx [5]
Thread [2] idx [5]
Thread [1] idx [6]
Thread [2] idx [6]
Thread [1] idx [7]Thread [2] idx [7]
Thread [1] idx [8]
Thread [2] idx [8]
Thread [1] idx [9]
Thread [2] idx [9]
Thread [1] idx [10]
Thread [2] idx [10]
</pre>
Does anyone know if my semaphore code is correct, and if it is why the output file seems to get incorrect data.
Semaphore problem
Here's how I've done it, and it seems to work correctly:
// Create the mutex.
SceUID mutex = sceKernelCreateSema("myMutexName", 0, 1, 1, 0);
// Wait until the mutex is available. (Implicitly decrements its value)
sceKernelWaitSema(mutex, 1, 0);
// Do your protected stuff here...
// Unlock the mutex.
sceKernelSignalSema(mutex, 1);
Hope this helps, please someone correct me if it's not right.
Pete
// Create the mutex.
SceUID mutex = sceKernelCreateSema("myMutexName", 0, 1, 1, 0);
// Wait until the mutex is available. (Implicitly decrements its value)
sceKernelWaitSema(mutex, 1, 0);
// Do your protected stuff here...
// Unlock the mutex.
sceKernelSignalSema(mutex, 1);
Hope this helps, please someone correct me if it's not right.
Pete
I'll try that
Look I'll try that, seems i thought of the semaphore the wrong way, it increments, and yes I realise this this is pretty standard.PeterM wrote:Here's how I've done it, and it seems to work correctly:
// Create the mutex.
SceUID mutex = sceKernelCreateSema("myMutexName", 0, 1, 1, 0);
// Wait until the mutex is available. (Implicitly decrements its value)
sceKernelWaitSema(mutex, 1, 0);
// Do your protected stuff here...
// Unlock the mutex.
sceKernelSignalSema(mutex, 1);
Hope this helps, please someone correct me if it's not right.
Pete
Thanks for the help hopefully it will work,
Just quickly though do I need to use 'SceUID' or is 'int' good enough, as the docs I have indicate that most threading methods return and 'int' corresponding to the thread or semaphore.
A few of the PSPSDK functions seem to take or return ints when there are appropriate enums or other types.
I guess it doesn't matter too much.
Anyway, the thing that confused me when trying semaphores for the first time was that waiting for one implicitly subtracted 1 from its value, so if you wait for it to become "1", when you get it, it will then be "0".
Then when you're done, you signal it, adding 1 to it, to make it "1" again. Then anyone else waiting for it to be "1" will get it.
Hope it helped.
I guess it doesn't matter too much.
Anyway, the thing that confused me when trying semaphores for the first time was that waiting for one implicitly subtracted 1 from its value, so if you wait for it to become "1", when you get it, it will then be "0".
Then when you're done, you signal it, adding 1 to it, to make it "1" again. Then anyone else waiting for it to be "1" will get it.
Hope it helped.
That was exactly it, I totally forgot that when you wait on the semaphore value it will decrement it once the value has been obtained, and hence if you look at my original code that is a problem.PeterM wrote:Anyway, the thing that confused me when trying semaphores for the first time was that waiting for one implicitly subtracted 1 from its value, so if you wait for it to become "1", when you get it, it will then be "0".
Then when you're done, you signal it, adding 1 to it, to make it "1" again. Then anyone else waiting for it to be "1" will get it.
Hope it helped.
Look I'm not sure this will fix my problem, but unfortunately the game I'm writing has a timer thread and controller thread, and they both must modify the data structure used to control the game display.
Anyways I'm sure this is the problem, thanks very much.
'SceID' is defined as 'int' at the moment, so you could just use 'int'. However, in theory, Sony could change the type and code that used 'int' *could* break. So you're not gaining anything by using 'int', and it's good coding practice to use the right type.do I need to use 'SceUID' or is 'int' good enough