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