[GiNaC-list] How (not) thread-safe is ginac?

[Thomas Bächler]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://www.cebix.net/pipermail/ginac-list/attachments/20081123/5e9c12e6/attachment.sig