Peter N Lewis wrote:
This issue came up on the MacPascal list, but since I recently ran across an RTS thread safety issue, I thought I'd post it here too, at least for reference if not for anything else.
There is a multi-platform multi-threading unit for gpc, see http://www.gnu-pascal.de/crystal/gpc/en/mail10658.html (but also read http://www.gnu-pascal.de/crystal/gpc/en/thread10512.html).
One thing I didn't see mentioned in the thread, but I discovered recently is that the routines like ReadStr/WriteStr are not thread safe. In particular they use a global variable (LastReadWriteStrFDR) for the file handle internally (to avoid re-allocating it each time), which is not MP thread safe. Also, they use an IOResult global variable (InOutRes variable).
To properly handle MP threading, the RTS would, at the least, require everything to have a returned error result, rather than using IOResult, which would be a big change (although this would be desirable for New as well).
There is no need to eliminate variables. GCC (starting from version 3.3) supports thread local variables. At least on Linux access to thread local variables is reasonably cheap (only slightly more expensive then nomal variables). So, one can turn IOResult into thread local variable and use it as before.
Of course, for this also GPC should support thread local variables. ATM GPC does not support thread local variables, mainly because we want to have the same feature set with all backends and older backends (IIRC 3.2 and earlier) do not support them.
Also, thread safety may have considerable cost on single-threaded programs. For example Java and glibc try to be thread safe, and in effect some single-threaded run about 5 times slower than thread unsafe versions. I think that we shall pay the price, but I do not know what other think.