title: How to make atomic exchange -- Scala way?
body: <h2>Problem</h2>
  
  <p>I have such code </p>
  
  <pre><code>var ls = src.iter.toList
  src.iter = ls.iterator
  </code></pre>
  
  <p>(this is part of copy constructor of my iterator-wrapper) which reads the source iterator, and in next line set it back. The problem is, those two lines have to be atomic (especially if you consider that I change the source of copy constructor -- I don't like it, but well...).</p>
  
  <p>I've read about Actors but I don't see how they fit here -- they look more like a mechanism for asynchronous execution. I've read about Java solutions and using them in Scala, for example: <a href="http://naedyr.blogspot.com/2011/03/atomic-scala.html" rel="nofollow noreferrer">http://naedyr.blogspot.com/2011/03/atomic-scala.html</a></p>
  
  <p>My question is: what is the most Scala way to make some operations atomic? I don't want to use some heavy artillery for this, and also I would not like to use some external resources. In other words -- something that looks and feels "right".</p>
  
  <p>I kind like the solution presented in the above link, because this is what I exactly do -- exchange references. And if I understand correctly, I would guard only those 2 lines, and other code does not have to be altered! But I will wait for definitive answer.</p>
  
  <h2>Background</h2>
  
  <p>Because every Nth question, instead of answer I read "but why do you use...", here:
  <a href="https://stackoverflow.com/questions/7797990/how-to-copy-iterator-in-scala">How to copy iterator in Scala?</a> :-)</p>
  
  <p>I need to copy iterator (make a fork) and such solution is the most "right" I read about. The problem is, it destroys the original iterator.</p>
  
  <h3>Solutions</h3>
  
  <p><strong>Locks</strong></p>
  
  <p>For example here:
  <a href="http://www.ibm.com/developerworks/java/library/j-scala02049/index.html" rel="nofollow noreferrer">http://www.ibm.com/developerworks/java/library/j-scala02049/index.html</a></p>
  
  <p>The only problem I see here, that I have to put lock on those two lines, and every other usage on iter. It is minor thing now, but when I add some code, it is easy to forget to add additional lock.</p>
  
  <p>I am not saying "no", but I have no experience, so I would like to get answer from someone who is familiar with Scala, to point a direction -- which solution is the best for such task, and in long-run.</p>
  
  <p><strong>Immutable iterator</strong></p>
  
  <p>While I appreciate the explanation by Paradigmatic, I don't see how such approach fits my problem. The thing is IteratorWrapper class has to wrap iterator -- i.e. raw iterator should be hidden within the class (usually it is done by making it private). Such methods as hasNext() and next() should be wrapped as well. Normally next() alters the state of the object (iterator) so in case of immutable IteratorWrapper it should return both new IteratorWrapper and status of next() (successful or not). Another solution would be returning NULL if raw next() fails, anyway, this makes using such IteratorWrapper not very handy.</p>
  
  <p>Worse, there is still not easy way to copy such IteratorWrapper.</p>
  
  <p>So either I miss something, or actually classic approach with making piece of code atomic is cleaner. Because all the burden is contained inside the class, and the user does not have to pay the price of they way IteratorWrapper handles the data (raw iterator in this case).</p>