Still, <div><br></div><div>i will complete the testing phase, and i will share my results. and if it worked i will give you some statistics of the behaveiur of the program, (seccesful launchs, rate of segfaults, wrong answers)</div>
<div> <br><br><div class="gmail_quote">On Sun, Jun 13, 2010 at 11:26 AM, Jens Vollinga <span dir="ltr"><<a href="mailto:jensv@nikhef.nl">jensv@nikhef.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
Am 13.06.2010 16:30, schrieb Alexei Sheplyakov:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm afraid you've missed the point. I wanted to explain that one of<br>
the essential mechanisms used by GiNaC (memory management) is not thread<br>
safe, therefore all setups (except using GiNaC from one thread) are unsafe.<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just think using GiNaC from several threads is more dangerous than<br>
Russian roulette :)<br>
</blockquote>
<br></div>
oh, please wait, reconsider! Your opinion might backfire someday ... ;-)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Automatic evaluation is not thread safe.<br>
</blockquote>
<br></div>
yes, but ...<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Have a look at ex::construct_from_basic (which is basically the core<br>
of automatic evaluation). That code does<br>
<br>
318 // If the original object is not referenced but heap-allocated,<br>
319 // it means that eval() hit case b) above. The original object is<br>
320 // no longer needed (it evaluated into something different), so we<br>
321 // delete it (because nobody else will).<br>
322 if ((other.get_refcount() == 0)&& (other.flags& status_flags::dynallocated))<br>
323 delete&other; // yes, you can apply delete to a const pointer<br>
324<br>
<br>
The reference counting is not thread safe, so the object can be deleted while<br>
it's used by another thread.<br>
</blockquote>
<br></div>
... all objects in his setup are 100% private to each thread. So I don't see a problem.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. GiNaC smart pointers are not thread safe. In theory it can be fixed<br>
by using atomic integers for reference counting, and locking in<br>
makewritable().<br>
<br>
3. GiNaC uses STL containers to store sums and products. STL containers are<br>
not thread safe at all.<br>
<br>
4. Subs() uses writable access (let_op()), and has no locking at all.<br>
</blockquote>
<br></div>
Same box.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I didn't mention refcounting, because I think in his setup it doesn't<br>
cause a problem, or does it?.<br>
</blockquote>
<br>
No matter what your setup is, you're going to use the automatic evaluation<br>
(otherwise you don't need GiNaC at all). And it's not thread safe (due to<br>
reference counting, data structures, etc). So the only safe setup is using<br>
GiNaC from one thread.<br>
</blockquote>
<br></div>
I think the only problem (in his setup) is a possible call to the gcd code.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm afraid locks will ruin any performance gains. I mean, if you need to<br>
take a lock every time you need to add two and integers or allocate several<br>
bytes of RAM, you can't achive any reasonable performance.<br>
</blockquote>
<br></div>
You were right if you made ginac thread-safe in a naive way, i.e. many locks protecting refcounting, functions, etc.<br>
<br>
While I don't know about cln, yet, in ginac it can be done in a smarter way. Instead of making ginac absolutely thread-safe in any use-case, one can enable the user to specify data/expression segments to which certain expressions, symbols or whatever should belong. Then, ginac ensures that it is thread-safe between these different segments. Some extra functions to let the user share or transport data between the segments need to be implemented and voila. That is just a rough idea, but the threading overhead would be minimized to keep it attractive.<br>
<br>
Regards,<br><font color="#888888">
Jens</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
GiNaC-list mailing list<br>
<a href="mailto:GiNaC-list@ginac.de" target="_blank">GiNaC-list@ginac.de</a><br>
<a href="https://www.cebix.net/mailman/listinfo/ginac-list" target="_blank">https://www.cebix.net/mailman/listinfo/ginac-list</a><br>
</div></div></blockquote></div><br></div>