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

Cristobal Navarro axischire at gmail.com
Sun Jun 13 21:44:13 CEST 2010


i would to clear a little!

the expressions are independant from each thread,

exp1 = x*y+....

exp2 = x+x+x+x...

exp3 = y+y*y+3...
..
..
expn = just_symbols..

no subexpressions never.

when i wrote point 4), i meant that the matrix is where these expressions
go, each thread puts its expression in a unique cell.

its just as you first though Jens,


Cristobal <http://www.youtube.com/neoideo>


On Sun, Jun 13, 2010 at 2:37 PM, Jens Vollinga <jensv at nikhef.nl> wrote:

> Hi!
>
> Am 13.06.2010 20:05, schrieb Alexei Sheplyakov:
>
>  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.
>>
>
> ah, now I see why we keep arguing: I misread point 4 completely!!! I
> thought he meant to have a clear the separation of expressions between
> threads (matrix and cell as tech-speak synonyms for groups of expressions,
> but NO, he meant really matrices and cells ..., stupid me!).
>
>
>  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
>> routines.
>>
>
> Well, someone says: you have static variables inside functions there. A
> thread-switch might occur during the construction, I guess.
>
> Regards,
> Jens
>
> _______________________________________________
> 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/cb44a79d/attachment.htm>


More information about the GiNaC-list mailing list