[CppAD] Multithreading

[bradbell at seanet.com]

1. If you do not call hold_memory
  http://www.coin-or.org/CppAD/Doc/ta_hold_memory.xml
then CppAD will not hold onto memory for quick use by the same thread;
i.e., the behavior will be very close to using the original system
allocator.

2. It is still in the CppAD API requirements to call parallel_setup
   http://www.coin-or.org/CppAD/Doc/ta_parallel_setup.xml
before using CppAD with multiple threads.

3. I am not sure I understand the discussion below. Are you trying to use
CppAD without calling parallel_setup ? Or have you found a bug in CppAD ?


> Hi Dominik,
>
> Is this occurring because thread_alloc expects memory to be freed from
> the same thread where it's allocated?
>
>> Or is it really true that independently  allocating memory in
>> one thread  slows down everything even so no mutex mechanism is needed?
>
> This can happen when using a malloc that isn't designed for threading
> workloads, but it's easy to select an alternate malloc on modern
> systems. For example under Linux/x86 and Linux/x86-64 options include
> TCMalloc, jemalloc, TBBmalloc, and hoard. In practice I would
> recommend just using the system malloc until you've determined that
> the malloc is actually a performance problem. The important thing
> however is to use a *thread-safe* malloc, for example under Linux with
> GCC you should pass the "-pthreads" option to GCC when compiling and
> linking. (It may not be enough to pass "-lpthread" when linking since
> "-pthreads" enables other options too.)
>
> Attached is a rudimentary patch that switches thread_alloc to use
> operator new and delete directly. You might want to give that a shot.
>
> However, even after using this patch and building with -DNDEBUG, I
> still get some warnings from helgrind about data races in
> CppAD::ADFun<double>::operator=, and I don't know whether they are
> simply spurious warnings. I'm planning to switch to a multiprocess
> model using mmap(MAP_SHARED) and fork() to avoid these issues.
>
> -Jey
>
> On Mon, Mar 19, 2012 at 9:00 AM, Dominik Skanda
> <Dominik.Skanda at biologie.uni-freiburg.de> wrote:
>> Concerning my last message, I have looked a little bit deeper in the
>> code and found out that essentially the command
>>
>> pod_vector<Base> Partial;
>> Partial.extend(total_num_var_ * p);
>>
>> in reverse.hpp causes the error.
>> So  as far as I think the Vector Partial is only accesed within the
>> function
>>
>> "VectorBase ADFun<Base>::Reverse(size_t p, const VectorBase &w)"
>>
>> and therefore should be thread safe (Since it is no global variable)! On
>> the other side due to the new memory allocater it is not. I think that
>> the new memory allocator should only be used were global information is
>> created. Or is it really true that independently  allocating memory in
>> one thread  slows down everything even so no mutex mechanism is needed?
>> This would made the applicability of the CppAD Library really much more
>> flexible!
>>
>>
>> _______________________________________________
>> CppAD mailing list
>> CppAD at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/cppad
> _______________________________________________
> CppAD mailing list
> CppAD at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cppad
>