[GiNaC-list] How (not) thread-safe is ginac?
thomas.baechler at gmx.de
Sun Nov 23 13:44:35 CET 2008
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://www.cebix.net/pipermail/ginac-list/attachments/20081123/5e9c12e6/attachment.sig
More information about the GiNaC-list