[GiNaC-list] is ginac thread safe for this case?
alexei.sheplyakov at gmail.com
Sun Jun 13 20:05:57 CEST 2010
On Sun, Jun 13, 2010 at 05:26:16PM +0200, Jens Vollinga wrote:
> >I'm afraid you've missed the point. I wanted to explain that one of
> >the essential mechanisms used by GiNaC (memory management) is not thread
> >safe, therefore all setups (except using GiNaC from one thread) are unsafe.
> this I don't believe yet. Maybe I am wrong, but the setup as he
> described it has no (and will not have any) sharing of
> subexpressions between threads.
I'm afraid tracking shared subexpressions is somewhat nontrivial. Consider
the following example:
ex a = pow(x1 + x2 + x3, 2);
ex b = pow(x1 - x2 - x3, 3);
e = a*b;
e = (a*b).diff(x1);
Expressions e and e share a and b (that's just a funny implementation
Suppose thread A operates on e and thread B operates on e:
// thread A
e = e.expand(); // no references to a and b any more
// thread B
e = e.diff(x2); // a*b'' + 2*a'*b' + a''*b, one more reference to a and b
Thread A has no references to a and b after expand() completes its job,
so it will try to decrement their refcount. On the other hand, thread B
will try to increment refcounts of a and b. That's a disaster, since
nothing protects refcount from concurrent modification.
[It's easy to find out shared subexpressions in the above example, but
in general it's not the case, unfortunately]
> 4) threads access the same common matrix of expressions, but two threads
> will never access the same cell.
This does NOT guarantee that you (or GiNaC on your behalf) won't operate
on a same (sub)expression from different threads. You *really* need a thread
safe (or atomic) reference counting to solve this problem.
> I think the only problem (in his setup) is a possible call to the gcd code.
As far as I understand GCD code is not any worse in this regard (that said,
it's not any better either). I might be wrong (I'm just a human being), so
I'd be grateful if someone could point out any non-reentrant code in GCD
> >I'm afraid locks will ruin any performance gains. I mean, if you need to
> >take a lock every time you need to add two and integers or allocate several
> >bytes of RAM, you can't achive any reasonable performance.
> You were right if you made ginac thread-safe in a naive way, i.e.
> many locks protecting refcounting, functions, etc.
I have some experience with those `somewhat thread safe' libraries, therefore
I strongly dislike this kind of ... cleverness (let's put it this way).
More information about the GiNaC-list