Dominik, could you provide a standalone testcase that would allow us to reproduce the problem you're experiencing?<br>
<br>Brad,<br><br>> 3. I am not sure I understand the discussion below. Are you trying to use<br>> CppAD without calling parallel_setup ? Or have you found a bug in CppAD ?<br>
<br>I am calling parallel_setup, and I don't know whether everything is working correctly or not. I'm using helgrind to check for threading errors, and it does issue some warnings in CppAD::ADFun<double>::operator=, but helgrind tends to be conservative in the errors it reports and could be simply complaining about code that is actually thread safe.<br>
<br>I don't quite understand the motivation for the thread_alloc machinery.<br><br>-Jey<br><br><br><div class="gmail_quote">On Mon, Mar 19, 2012 at 3:25 PM, <span dir="ltr"><<a href="mailto:bradbell@seanet.com">bradbell@seanet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">1. If you do not call hold_memory<br>
<a href="http://www.coin-or.org/CppAD/Doc/ta_hold_memory.xml" target="_blank">http://www.coin-or.org/CppAD/Doc/ta_hold_memory.xml</a><br>
then CppAD will not hold onto memory for quick use by the same thread;<br>
i.e., the behavior will be very close to using the original system<br>
allocator.<br>
<br>
2. It is still in the CppAD API requirements to call parallel_setup<br>
<a href="http://www.coin-or.org/CppAD/Doc/ta_parallel_setup.xml" target="_blank">http://www.coin-or.org/CppAD/Doc/ta_parallel_setup.xml</a><br>
before using CppAD with multiple threads.<br>
<br>
3. I am not sure I understand the discussion below. Are you trying to use<br>
CppAD without calling parallel_setup ? Or have you found a bug in CppAD ?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> Hi Dominik,<br>
><br>
> Is this occurring because thread_alloc expects memory to be freed from<br>
> the same thread where it's allocated?<br>
><br>
>> Or is it really true that independently allocating memory in<br>
>> one thread slows down everything even so no mutex mechanism is needed?<br>
><br>
> This can happen when using a malloc that isn't designed for threading<br>
> workloads, but it's easy to select an alternate malloc on modern<br>
> systems. For example under Linux/x86 and Linux/x86-64 options include<br>
> TCMalloc, jemalloc, TBBmalloc, and hoard. In practice I would<br>
> recommend just using the system malloc until you've determined that<br>
> the malloc is actually a performance problem. The important thing<br>
> however is to use a *thread-safe* malloc, for example under Linux with<br>
> GCC you should pass the "-pthreads" option to GCC when compiling and<br>
> linking. (It may not be enough to pass "-lpthread" when linking since<br>
> "-pthreads" enables other options too.)<br>
><br>
> Attached is a rudimentary patch that switches thread_alloc to use<br>
> operator new and delete directly. You might want to give that a shot.<br>
><br>
> However, even after using this patch and building with -DNDEBUG, I<br>
> still get some warnings from helgrind about data races in<br>
> CppAD::ADFun<double>::operator=, and I don't know whether they are<br>
> simply spurious warnings. I'm planning to switch to a multiprocess<br>
> model using mmap(MAP_SHARED) and fork() to avoid these issues.<br>
><br>
> -Jey<br>
><br>
> On Mon, Mar 19, 2012 at 9:00 AM, Dominik Skanda<br>
> <<a href="mailto:Dominik.Skanda@biologie.uni-freiburg.de">Dominik.Skanda@biologie.uni-freiburg.de</a>> wrote:<br>
>> Concerning my last message, I have looked a little bit deeper in the<br>
>> code and found out that essentially the command<br>
>><br>
>> pod_vector<Base> Partial;<br>
>> Partial.extend(total_num_var_ * p);<br>
>><br>
>> in reverse.hpp causes the error.<br>
>> So as far as I think the Vector Partial is only accesed within the<br>
>> function<br>
>><br>
>> "VectorBase ADFun<Base>::Reverse(size_t p, const VectorBase &w)"<br>
>><br>
>> and therefore should be thread safe (Since it is no global variable)! On<br>
>> the other side due to the new memory allocater it is not. I think that<br>
>> the new memory allocator should only be used were global information is<br>
>> created. Or is it really true that independently allocating memory in<br>
>> one thread slows down everything even so no mutex mechanism is needed?<br>
>> This would made the applicability of the CppAD Library really much more<br>
>> flexible!<br>
>><br>
>><br>
>> _______________________________________________<br>
>> CppAD mailing list<br>
>> <a href="mailto:CppAD@list.coin-or.org">CppAD@list.coin-or.org</a><br>
>> <a href="http://list.coin-or.org/mailman/listinfo/cppad" target="_blank">http://list.coin-or.org/mailman/listinfo/cppad</a><br>
> _______________________________________________<br>
> CppAD mailing list<br>
> <a href="mailto:CppAD@list.coin-or.org">CppAD@list.coin-or.org</a><br>
> <a href="http://list.coin-or.org/mailman/listinfo/cppad" target="_blank">http://list.coin-or.org/mailman/listinfo/cppad</a><br>
><br>
<br>
<br>
</div></div></blockquote></div><br>