mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <sro...@gmail.com>
Subject Re: deadlock in FastByIDMap.find() ?
Date Thu, 10 Dec 2009 09:19:32 GMT
So, Weiwei, the issue was identified as relates to FastMap, not
FastByIDMap -- though the implementations are virtually the same.
Also, it does not look like it had to do with an instance you created,
but one used in a Cache. Therefore I am not sure that changing an
instance you use directly has any effect.

Did you have a chance to try the latest code? I added some checks for
bad states, temporarily, that would dump information if something goes
wrong.

No the iterator remove stuff looks OK to me:

  void iteratorRemove(int lastNext) {
    if (lastNext >= values.length) {
      throw new NoSuchElementException();
    }
    if (lastNext < 0) {
      throw new IllegalStateException();
    }
    values[lastNext] = null;
    ((Object[]) keys)[lastNext] = REMOVED;
    numEntries--;
  }


It's not a remove that would fill up the table, it's an add, that's
not accompanied by possible growth. I am still not able to find the
issue by inspection.

But again recall that the issue wasn't in an instance Weiwei used
directly, but one used indirectly in a Cache. Which is all the more
puzzling, since I've even added tests to try to reproduce any problem
in this area I can imagine, and nothing seems to be wrong yet.



On Thu, Dec 10, 2009 at 1:24 AM, Ted Dunning <ted.dunning@gmail.com> wrote:
> Sean, is this the necessary hint?
>
> Are there removal markers that don't get handled in subsequent insertions?
>
> 2009/12/9 施伟伟 <shiweiwei97@gmail.com>
>
>> BTW, I am using iterator.remove() to remove elements from FastByIDMap &
>> FastIDSet.
>> Will this be a problem?
>>
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>

Mime
View raw message