Martin Bähr <<mbaehr[at]email.archlab.tuwien.ac.at>> wrote:
> On Thu, Jan 15, 2009 at 12:45:05PM +0100, Martin Stjernholm wrote:
>> Unfortunately it seems you're right. I'm sorry for the misinformation.
>> The behavior I described only applies to multisets; I thought mappings
>> were fixed to behave similarly.
>
> what exactly is being fixed here?
I referred to removing the copy-on-write behavior for mapping
iterators. More consistency between mapping and multiset behavior
would be good.
>> But in cases where an implicit deferred copy is unwanted overhead, it
>> cannot be avoided with the current mapping behavior.
>
> you mean, it can't be avoided because the mapping is set copy-on-write?
> so the fix is to avoid copy-on-write (but introduce undetermined
> behavior for new elements as a (maybe minor) downside. is that correct?
Yes.
> how does the copy-on-write work? wouldn't the m_delete like in stephens
> example also trigger that?
Yes, it would. That's the overhead that can't be avoided due to the
implicit copy-on-write. This could become a serious issue if the
mapping is a very large frequently updated cache: One might be forced
to avoid creating iterators on it altogether just to avoid the risk of
getting large unwanted copies.
Btw, if mappings are to be lock-free in a future multi-cpu
implementation then copy-on-write would imply another overhead: If I'm
not mistaken, a memory fence would be necessary in every mapping
update. It's a very good question whether or not copy-on-write is
worth that price.
|