[Dune-devel] [Dune-Commit] [Commit] dune-common - f78ce3a: [poolallocator, release] Use a non-static memory pool.

Steffen Müthing steffen.muething at iwr.uni-heidelberg.de
Mon Feb 3 11:45:42 CET 2014


Am 03.02.2014 um 11:03 schrieb Markus Blatt <markus at dr-blatt.de>:

> Hi Carsten,
> 
> On Thu, Jan 30, 2014 at 04:29:25PM +0100, Carsten Gräser wrote:
>> this looks like a (potentially dangerous) interface change to me.
>> Its a change since different instances of the same allocator
>> type are no longer equivalent. Furthermore its dangerous
>> for the following reason:
>> 
>> While an stl conforming allocator is in principle allowed to be
>> stateful, the standard also explicitly allows that stl implementations
>> may require that the allocator is stateless.
>> 
> 
> Is that really the case? I tried to find this in the C++11 standard,
> but to no avail. It even seems to be contrary to me, as there are
> interface methods like operator==(other) for testing whether memory
> allocated by one allocator might be deallocated by the other.
> 
> Seems like this was different in previous standards. But most
> implementations do support them:
> http://stackoverflow.com/questions/6861046/compiler-support-for-stateful-allocators-in-stl-containers
> 
>> Strictly speaking, you can no longer use the pool allocator
>> with stl containers unless you know that your specific stl
>> implementation supports stateful allocators.
>> 
> 
> Is anybody doing that? Poolallocator only allows to allocate 1 element
> at a time which rules out quite a few containers. At least in the core
> modules it only used in dune-istl's AMG and that is where it makes
> trouble.
> 
>> I'm not proposing to revert the patch and I'm also not sure how to
>> resolve this issue. I think thats one of the reasons why the allocator
>> design is said to be broken. However we should at least warn the user
>> in the docs and the release notes if we keep this patch.
> 
> If we agree that stateful allocator are supported by c++11 and above
> we could at least apply this behaviour for compilers which support
> that.

Well, Stroustrup says they are stateful in C++11 (see http://www.stroustrup.com/C++11FAQ.html#scoped-allocator,
and the paragraph about containers directly above). I think the support is needed for the new-fangled scoped
allocators.

On the other hand, they are definitely *not* allowed to be stateful in C++03 (even though, as you point out, most
library implementations have some support for that).

So I think adding support for C++11-compliant compilers is a good compromise.

Best,
Steffen


>> 
>> Best,
>> Carsten
>> 
>> Am 29.01.2014 19:51, schrieb Markus Blatt:
>>> New commit, appeared at Wed Jan 29 19:51:28 2014 +0100
>>> as part of the following ref changes:
>>> 
>>>    branch refs/heads/master    updated from 75e2716 -> f78ce3a
>>> 
>>> Browsable version: http://cgit.dune-project.org/repositories/dune-common/commit/?id=f78ce3a8db88ecda77664f6e7bfa480768e2e999
>>> 
>>> ======================================================================
>>> 
>>> commit f78ce3a8db88ecda77664f6e7bfa480768e2e999
>>> Author: Markus Blatt <markus at dr-blatt.de>
>>> Date:   Wed Jan 29 19:48:38 2014 +0100
>>> 
>>>    [poolallocator,release] Use a non-static memory pool.
>>> 
>>>    Due to its desgin of using one static memory pool. The allocator
>>>    could not be used in different threads at the same time without
>>>    side effects. With this revision each instance will hold its own private
>>>    instance of the pool.
>>> 
>>>    There should be no issues with this patch and poolallocator seems to be
>>>    mostly used in AMG anyway.
>>> 
>>> dune/common/poolallocator.hh | 5 +----
>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>> 
>>> 
>>> 
>>> diff --git a/dune/common/poolallocator.hh b/dune/common/poolallocator.hh
>>> index 9bb4897..e7555bd 100644
>>> --- a/dune/common/poolallocator.hh
>>> +++ b/dune/common/poolallocator.hh
>>> @@ -368,7 +368,7 @@ namespace Dune
>>>     /**
>>>      * @brief The underlying memory pool.
>>>      */
>>> -    static PoolType memoryPool_;
>>> +    PoolType memoryPool_;
>>>   };
>>> 
>>>   // specialization for void
>>> @@ -552,9 +552,6 @@ namespace Dune
>>>   }
>>> 
>>>   template<class T, std::size_t s>
>>> -  typename PoolAllocator<T,s>::PoolType PoolAllocator<T,s>::memoryPool_;
>>> -
>>> -  template<class T, std::size_t s>
>>>   inline PoolAllocator<T,s>::PoolAllocator()
>>>   { }
>>> 
>>> 
>>> _______________________________________________
>>> Dune-Commit mailing list
>>> Dune-Commit at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune-commit
>>> 
>> 
>> 
> 
> -- 
> Do you need more support with DUNE or HPC in general? 
> 
> Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
> Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany
> Tel.: +49 (0) 160 97590858  Fax: +49 (0)322 1108991658 
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20140203/46230263/attachment.sig>


More information about the Dune-devel mailing list