Iterator of TMap, TSet

40 views
Skip to first unread message

Lixing

unread,
Feb 28, 2013, 3:05:25 PM2/28/13
to scala-stm-e...@googlegroups.com
Hi,

I found the ScalaSTM Homepage says 'We have chosen to make TMap.View.iterator and TSet.View.iterator return an iterator over an atomic snapshot of the collection. The iterator method acts as if it has made a copy of the entire collection and returned an iterator over the copy. Concurrent updates can proceed uninhibited.'

I am wondering if this method is reasonable because I think the copy of the iterator may not represent the current keyset in the object. For example, after you copy the iterator, a transaction adds a key in TMap, and then you return the iterator. This iterator is old.

BTW, is it possible to share the implementation code for TMap iterator? I only found the interface in the project.

Thanks

Nathan Bronson

unread,
Feb 28, 2013, 3:39:00 PM2/28/13
to scala-stm-e...@googlegroups.com
Lixing,

The TMap implementation is part of the ScalaSTM source, it is in https://github.com/nbronson/scala-stm/blob/master/src/main/scala/scala/concurrent/stm/skel/HashTrieTMap.scala . The heavy lifting is all in a superclass that is shared between the set and the map: https://github.com/nbronson/scala-stm/blob/master/src/main/scala/scala/concurrent/stm/skel/TxnHashTrie.scala

If you are iterating outside a transaction it is not possible to provide both a consistent view of the map and the latest view of the map, since once iteration has begun the code using the iterator will have already seen part of the old state. It is certainly a design tradeoff to choose one or the other, but my experience is that the consistent snapshot is a more powerful and useful primitive. It is hard to implement (and very difficult to implement efficiently) at a level higher than the map itself. The freshness of the iterator, on the other hand, can be implemented either by rechecking or by running the iterating code inside a transaction.

 - Nathan


--
 
---
You received this message because you are subscribed to the Google Groups "Scala STM Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-stm-expert-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Nathan Grasso Bronson
ngbr...@gmail.com

Lixing

unread,
Mar 1, 2013, 3:05:54 PM3/1/13
to scala-stm-e...@googlegroups.com
Thanks. In that case,  I am confused how to make an atomic snapshot of the collection by avoiding the conflict of making a copy current key and value while another transaction is trying to modify the key and value.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-stm-expert-group+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Nathan Bronson

unread,
Mar 1, 2013, 3:29:43 PM3/1/13
to scala-stm-e...@googlegroups.com
You are right that a transaction that modifies the map and a transaction that makes a snapshot will conflict. The snapshot can outlive its creating transaction or be created outside a transaction entirely, in which case it can be stale.

 - Nathan


To unsubscribe from this group and stop receiving emails from it, send an email to scala-stm-expert-...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply all
Reply to author
Forward
0 new messages