[armedbear-devel] Losing on multiprocessing

[Alan Ruttenberg]

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 at 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<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."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20130926/6cbd7a45/attachment.html>