8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

[Paul Sandoz]

On Apr 4, 2014, at 1:42 AM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> 
>> I could live with that change in behaviour, but this change completely breaks the fail-fast semantics of the iterators in some cases! If you don't update modCount until after the change is complete, the iterator may access the updated state and not throw CME!.
> 
> For Vector I don't see this. The Iterator accesses to the data structures is always done with the Vector.this lock held. The re-ordering would only be observable to another thread if it is reading the Vector fields without holding the lock. I am not sure we should worry about that case.
> 

Agreed, i don't see how that can happen.


> For Hashtable Iterator there is no synchronization on the owning Hashtable except during the remove() method. It is unclear why the Hashtable iterators were not written in the same way as Vector.

Dunno.


> It seems like there would be massive disruption to adding synchronization to Hashtable's itertors. Are the Hashtable iterators actually fast-fail?

They are fail fast only from within the same thread when the control is inverted via iterator (like that for non-synchronized HashMap etc), otherwise it is necessary to explicitly synchronize on the iterator, much like that for Collections.synchronized* methods, see the implementation:

    public Set<K> keySet() {
        if (keySet == null)
            keySet = Collections.synchronizedSet(new KeySet(), this);
        return keySet;
    }

The documentation for keySet etc. states:

     * reflected in the set, and vice-versa.  If the map is modified
     * while an iteration over the set is in progress (except through
     * the iterator's own <tt>remove</tt> operation), the results of
     * the iteration are undefined.  The set supports element removal,


The documentation on the enumeration methods does not say anything.

We should probably update the documentation to additionally say something like that on Collections.synchronized* methods.


> Without synchronization this is not guaranteed since the writes may not be visible and Hashtable iterator failure behaviour is already likely to vary between platforms/architectures. With RTM it's presumed that the writes will NOT be visible until the transaction completes. This implies that the failure mode from Hashtable iterators is likely to change just by turning RTM locking on whether we make this code change or not. :-( 
> 

>> I think this change is misguided.
> 
> I think we are fine for Vector, but Hashtable gives me concerns even in it's current state.
> 

I don't think the current situation is made any worse by your changes.

The are some subtle changes with regards parameter checking and throwing exceptions, but that does not seems to be very important behaviour to preserve.

Paul.