..:: PCSX2 Forums ::..

That strange, may I suggest to create a define for every wrapper so you can easily test which one are slower/faster. How many thread do you use for benchmark? Last but not least good luck

Quote:However I have been reading on some forums that std::thread is just a wrapper for posix/win thread. If this is true, that would be a real shame, as pthread is already as close to the metal as we can get.

On linux it is easy to check download the std lib and see the code (I confirm pthread is used on llvm std C++) Anyway, I didn't expect any speed difference because API is better/worst. Speed increase could appears if previous pthread code was buggy. Besides it is a huge progress for portability. If it work well, PCSX2 thread could be replaced too.

Haha, I didn't even know you could adjust the number of threads. I figured that was all hardcoded in. Is that the setting under the plugin where it says "extra threads?"

Yes. You can see the number of thread in a debugger (gdb info thread)

Bonus work: give a different name for the extra thread

(04-26-2014, 11:07 PM)avih Wrote: [ -> ]Thanks for your work!

Thanks for the rep. But it is still in its very early stage. Once I am more familiar with the code I plan to add some real documentation.

I am proud of the linux compile guide though. That was my original work

Just some interesting facts, I looked into the gcc implementation of std::thread, and it does in fact use pthread at its core (I'm not sure there are any other options on a UNIX system anyway). Though I agree that portability and clean code are always desirable!

Ran into a little snafu today in that to do a std library implementation of IGSEvent, I need access to the mutex that is inside of an IGSLock. I may have to make some ENABLE_STD_THREAD-specific modifications to IGSEvent.

When debugging with GDB, how do I break at a line in GSThread.h? GDB doesn't seem to recognize that the file exists.

Are you sure you didn't misspell the file. Otherwise try to break first in a function that call those GSThread.h function. Then step into a function.You can add a breakpoint on the current file with this kind of command.

Alright... so I'm still a little perplexed on how to go about a std library implementation of GSEvent. GSEvent relies on plain semaphores, but std library does not give you access to raw semaphores as it was deemed "too much rope for programmers to hang themselves with". Instead you are supposed to make use of only std::thread, std::mutex, and std::condition_variable. In addition, you are required to use std::condition_variable in conjunction with a std::mutex, which makes working with interfaces difficult, GSEvent would need direct access to a member inside the GSCritSec.

TLDR; std::thread is designed to be a high-level library to begin with, so it is difficult to encapsulate.

I could just make a new branch and replace all threading in GSdx with std.

Hum, there is always surprise Let's take it easy and forget event (sema on linux) for the moment. But do we need GSevent actually? A quick grep seems to show that GSevents are only use on GSJobQueue. Condvar will replace them, correct? or did I miss somethings ?