Thanks for this! I'll have a look a little later - crazy day. It occurred to me that perhaps the automaton library wasn't re-entrant but I asked the developer and he thinks it is.

-Alan



On Thu, Sep 26, 2013 at 7:44 AM, Mark Evenson <evenson@panix.com> wrote:
On 9/26/13 0728 , Alan Ruttenberg wrote:
Howdy,

I wonder if those of you have worked with threads might have a quick
look to see if I am doing something stupid.

https://lsw2.googlecode.com/svn/branches/bona/util/jargrep.lisp

I whacked away at your file, converting it to the attached form to use the JSS namespace and ABCL-ASDF to resolve the dk.brics.automaton artifact, but I can't get to seem the matches to occur.   Not having your jar files to test, I just run it across Maven jars as follows:

CL-USER> (jar-map-threads-automaton-find "Manifest" (jss::all-jars-below "~/.m2"))
12.295 seconds real time
1897572 cons cells

0
0
CL-USER> (length (jss::all-jars-below "~/.m2"))
460

which should result in matches for all jars, because every jar that Maven uses, has a manifest contains the string "Manifest-Version: 1.0".  But I get no hits, and the execution is so fast, that I suspect that the matcher is not actually working on anything for some reason.  Since you pass a closure with a reference to the regex as the function to THEREADS:MAKE-THREAD, trying to TRACE stuff doesn't seem to work so well.

I need to spend more time with the matcher to understand why I am not generating any hits.  Any ideas on your end?

[…]


The result of running this is about (and their's the rub) 20 key value
pairs in the hash table (I had read that ABCL hash tables are thread
safe). The problem is that different runs of this code on the same data
get different numbers of key value pairs, between 13 and 24!

ABCL hashtables should indeed be thread-safe, with all accesses protected by an underlying java.util.concurrent.locks.ReentrantLock.



I'm not sure whether I'm just not doing this the right way, in which
case it would be very helpful to get an explanation of why not, or
there's a problem somewhere in the implementation.

For the record, I used

CL-USER> (lisp-implementation-version)
"1.3.0-dev"
"Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_40-b43"
"amd64-Linux-2.6.18-348.16.1.el5.centos.plus"

to run my tests, but I have no reason to currently suspect the ABCL version is at fault here.

More later when I get the time,
Mark




--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."