Yes, I thought of that too. It's a bit tricky. I'm also curious what the clojure implementation of this does. Also, do we want to make this cache thread-safe? We could use the spin lock implementation Atomic.scala (same package) if we needed to. 

> On Oct 10, 2013, at 6:15 PM, Jonathan Coveney <notifications@github.com> wrote:
> 
> In storehaus-cache/src/main/scala/com/twitter/storehaus/cache/LIRSCache.scala:
> 
> > + *     http://www.apache.org/licenses/LICENSE-2.0
> > + *
> > + * Unless required by applicable law or agreed to in writing, software
> > + * distributed under the License is distributed on an "AS IS" BASIS,
> > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> > + * See the License for the specific language governing permissions and
> > + * limitations under the License.
> > + */
> > +
> > +package com.twitter.storehaus.cache
> > +
> > +import scala.collection.SortedMap
> > +import scala.annotation.tailrec
> > +
> > +object Stack {
> > +  def apply[K](maxSize:Int,
> I thought about this, and I definitely agree. There's a bit more complication to it than than, though.
> You could have something with the inc 1, then another thing with the inc 2, then you thing with inc 2 starts cycling, so it goes up to 3, then 4, then 5, then it rolls over...how do you know that it's safe to roll over?
> 
> I've seen general schemes for this from the world of threading. It's not too hard, but it will add a bit of complexity to the code. If it's worth it, I'll do it (I think it's worth it).
> 
> —
> Reply to this email directly or view it on GitHub.