[GiNaC-list] is ginac thread safe for this case?

[Cristobal Navarro]

Thanks for every answer,

ill have to find a solution for this. i am liking ginac so much that i would
have been perfect if this was possible, but its ok !.
The algorithm is computing intensive (for research).

now i have two options
 i could search for another free symbolic library thread-safe (which for me
is unknown, does such library exist?) or
i could put and end to this and program myself a simple and thread-safe
symbol-expression environment for my needs, which are very reduced (i only
use polinomies, big in size but in the end they are polinomial expressions).


i guess i dont have anymore questions
thanks again everyone!
On Sun, Jun 13, 2010 at 10:30 AM, Alexei Sheplyakov <
alexei.sheplyakov at gmail.com> wrote:

> 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
>
> _______________________________________________
> GiNaC-list mailing list
> GiNaC-list at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cebix.net/pipermail/ginac-list/attachments/20100613/2d340bb8/attachment-0001.htm>