I am planning to use ginac for mathematic implementations which can (and should) be parallelized. However, I found hints that ginac is not thread-safe. The only thing in the source code was here: http://www.ginac.de/ginac.git?p=ginac.git;a=blob;f=ginac/ptr.h If I understand this right, the reference counting should be protected by mutexes and one would have to think of a way to avoid certain race conditions with makewritable(). What else is there in ginac that would need to be changed for thread-safety? Note that I do not plan to share any objects but only the symbols I use between threads, so I probably could (temporarily) work with a version that is only partially thread-safe. Thanks for your replies Thomas
Hi, just some short comments: Thomas Bächler schrieb:
I am planning to use ginac for mathematic implementations which can (and should) be parallelized. However, I found hints that ginac is not thread-safe. The only thing in the source code was here: http://www.ginac.de/ginac.git?p=ginac.git;a=blob;f=ginac/ptr.h
no, it isn't thread safe.
If I understand this right, the reference counting should be protected by mutexes and one would have to think of a way to avoid certain race conditions with makewritable(). What else is there in ginac that would need to be changed for thread-safety?
reference counting is one (important) place. Symbols get numbers assigned internally. This is also not thread-safe. Another source of problems are the look-up tables for the numeric evaluation of certain functions.
Note that I do not plan to share any objects but only the symbols I use between threads, so I probably could (temporarily) work with a version that is only partially thread-safe.
If you write a thread-safe symbol factory as an intermediate interface it might work. Regards, Jens
Jens Vollinga schrieb:
no, it isn't thread safe.
Are there any plans to make it thread-safe? I think this is a real show-stopper for many people. Take my example, I have some algorithms implemented in Maple right now, which is sometimes slow, has ugly code (due to lack of OO) and whose thread-capabilities (at least in version 11) are non-functional. ginac has all the basic capabilities I need, however I have a very powerful (=many CPUs) machine at my disposal. Threaded programming is thus very important here. From what you wrote, we have: 1) reference counting / makewritable 2) numbers assigned to symbols 3) lookup tables for function evaluation I'll start poking at this after Christmas, so it would be nice to have a more or less complete list of problems here. If you think of more (or can tell me there isn't more), then I would appreciate if you tell me.
If I understand this right, the reference counting should be protected by mutexes and one would have to think of a way to avoid certain race conditions with makewritable(). What else is there in ginac that would need to be changed for thread-safety?
reference counting is one (important) place. Symbols get numbers assigned internally. This is also not thread-safe.
The latter shouldn't be too difficult to fix though, right? I didn't look at the specific piece of code, but I guess it's just incrementing a counter that needs to be protected with a mutex.
Another source of problems are the look-up tables for the numeric evaluation of certain functions.
Not too important for me, I only care about polynomial and rational functions arithmetics, no function evaluation done anywhere.
Note that I do not plan to share any objects but only the symbols I use between threads, so I probably could (temporarily) work with a version that is only partially thread-safe.
If you write a thread-safe symbol factory as an intermediate interface it might work.
That won't be a problem for me, as I create all the symbols used in the beginning and never add new ones later. My biggest fear was that internal ginac functions might use static buffers extensively and major things would have to be rewritten. From your statements so far, it doesn't look that way. This would be my first real experience with multi-threaded programming though, so I might not see the whole picture.
participants (2)
-
Jens Vollinga
-
Thomas Bächler