gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Semeai


From: Daniel Bump
Subject: Re: [gnugo-devel] Semeai
Date: Fri, 25 Jan 2002 22:18:28 -0800

Gunnar wrote:

> > However there is still a problem that the hash key
> > only depends on one dragon, which could conceivably
> > be involved in multiple semeais. The solution I found
> > to this is to run reading_cache_clear() from the
> > non-recursive owl_analyze_semeai() after
> > do_owl_analyze_semeai() returns.
> 
> This is clearly not acceptable as a long-term solution.

At the moment this may be OK since the semeai code is called
fairly seldom, compared with owl_attack or owl_defend.

However the crashes were indication of something seriously
wrong and I think I've figured it out.

The crashes were mitigated but not eliminated by adding
this call to reading_cache_clear(). They occurred in
hashtable_partially_clear, sometimes long after the
semeai code was finished.

After a lot of mucking around I convinced myself that
the Hashnode next pointer was getting trashed and it seemed
the function hashtable_partially_clear() itself was
responsible. So I changed one line of that function to:

    hashtable_unlink_closed_results(node, 
                            (1 << OWL_ATTACK |
                            1 << OWL_DEFEND  |
                            1 << SEMEAI), 3, statistics);

and the crashes seem to have stopped. I'm most of the
way through the third regression batch (running strategy3.tst
right now).

I can't say that I understand clearly what's going on
but I'll bet it's now fixed. I won't put up a revised patch
until tomorrow. If there is no crash I'll probably put
this in the CVS when I get up tomorrow morning.

This does not mean that we can take out the calls to 
reading_cache_clear() entirely. It's still needed because
apos does not determine the semeai.

Dan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]