Cool! I'll check out the CyclicIncrementer now. It's up to Oscar if he
wants to use it for LRUCache. :) Also, sorry I was thinking of the thread
safety issue from the consumer's perspective, but I think that's probably
outside of the scope of what storehaus is providing. For example, if I want
to use this LIRSCache in a system where items are being inserted by
multiple threads, I have to ensure that I use something like Atomic (i.e.,
java.util.concurrent.AtomicReference) to ensure that multiple puts/writes
are not "lost" among the new instances of the cache getting returned on
each put operation.


On Fri, Oct 11, 2013 at 2: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 added a CyclicIncrementer which solves this problem in a pretty generic
> way. Want me to use it for LRUCache? Also, thread safe in what way? It's
> immutable! ;)
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/twitter/storehaus/pull/155/files#r6926979>
> .
>