[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