On Sun, Jun 13, 2010 at 01:27:26PM +0200, Jens Vollinga wrote:
> I completely agree with your last sentence! This is what I wrote in
> my last mail
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.
> (but maybe you consider Russian roulette not as dangerous as I do ... ;-) ).
I just think using GiNaC from several threads is more dangerous than
Russian roulette :)
> I just wanted to explain more than just saying "It doesn't work.".
Ok, if someone wants the gory details...
1. Automatic evaluation is not thread safe.
Have a look at ex::construct_from_basic (which is basically the core
of automatic evaluation). That code does
318 // If the original object is not referenced but heap-allocated,
319 // it means that eval() hit case b) above. The original object is
320 // no longer needed (it evaluated into something different), so we
321 // delete it (because nobody else will).
322 if ((other.get_refcount() == 0) && (other.flags & status_flags::dynallocated))
323 delete &other; // yes, you can apply delete to a const pointer
324
The reference counting is not thread safe, so the object can be deleted while
it's used by another thread.
2. GiNaC smart pointers are not thread safe. In theory it can be fixed
by using atomic integers for reference counting, and locking in
makewritable().
3. GiNaC uses STL containers to store sums and products. STL containers are
not thread safe at all.
4. Subs() uses writable access (let_op()), and has no locking at all.
> I didn't mention refcounting, because I think in his setup it doesn't
> cause a problem, or does it?.
No matter what your setup is, you're going to use the automatic evaluation
(otherwise you don't need GiNaC at all). And it's not thread safe (due to
reference counting, data structures, etc). So the only safe setup is using
GiNaC from one thread.
> >Only few symbolic algorithms can be parallelized, and performance gain
>
> That might be true for "schoolbook" algorithms like gcd,
> factorization, etc, but not for more complex computational tasks
> involving cascades of manipulation steps performed on large number
> of expressions.
>
> >(if any) is not that big. So why bother?
>
> Aforementioned tasks can in principle hope for huge performance
> gains depending on the number of cpu cores.
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.
Best regards,
Alexei