Perhaps a stupid question, but is LockMutex() threadsafe by itself?
Do I need to compile with ThreadSafety ON?
On my comp (single-core/ threadSafety OFF) my code works as expected, but I am a bit worried if the same applies for multi-cores.
LockMutex() and Threadsafety
The number of cores should not matter to the application as that is all handled by the OS. If it works on a single core then it should work on a multicore machine.
As a rule though, and someone should correct me if I'm wrong, if you are programming multiple threads, and you must be otherwise LockMutex() would have no point, then you should enable threadsafe as a compiler option.
From the PB help
As a rule though, and someone should correct me if I'm wrong, if you are programming multiple threads, and you must be otherwise LockMutex() would have no point, then you should enable threadsafe as a compiler option.
From the PB help
This is the practice I've followed so far anyway.PureBasic has a special compiler setting to create threadsafe executables. (/THREAD commandline switch or "create threadsafe executable" in the IDE compiler options). Without this mode, certain functions (and also the string access) are faster, but not save to use in threads. It is still possible to create threads without this mode but it is not recommended, as even something simple like a local string access can be dangerous and needs to be protected. Enabling this option makes these things save inside threads, but comes at the price of some speed. The decision on wether or not to use threads should therefore done with care, and the threadmode should only be used when there is a real need for it.
Missed it by that much!!
HK
HK
especially if using a lot of different PB Lib functions inside threads, the option is required for threadsafety in the PB code. As mentioned above, when threadsafe is on the functions are a bit slower so they are left somewhat unsafe by design for performance.
Mutexs etc are for your code and syncing access to your data.
Threadsafe is for PB's code and PB's data.
Atleast that's how I understand it
Mutexs etc are for your code and syncing access to your data.
Threadsafe is for PB's code and PB's data.
Atleast that's how I understand it
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Sure, I understand that.pdwyer wrote:Mutexs etc are for your code and syncing access to your data.
Threadsafe is for PB's code and PB's data.
But the question remains : is LockMutex() threadsafe by itself (without that compiler-option "Threadsafe") OR should I use the Win-Api counterparts which are by nature threadsafe. (SignalObjectAndWait/WaitForSingleObject)
I do not want to use ThreadSafe ON...
The question seems a redundant one to me; PB's mutex objects are simply (in the case of Windows) critical sections used to protect shared resources within a single application. As such this is a Windows construct and not a PB one and Windows, being a multi-tasking OS, is thereadsafe by default! 
Use CreateMutex() with or without the threadsafe switch. Of course you would likely only use this in a multi-threaded application anyhow and you are then strongly advised to set the threadsafe switch in these circumstances.
Use CreateMutex() with or without the threadsafe switch. Of course you would likely only use this in a multi-threaded application anyhow and you are then strongly advised to set the threadsafe switch in these circumstances.
I may look like a mule, but I'm not a complete ass.