[snmp] Possible flaw in transmitter?

[Andy Chandler]

    I'm tracking an elusive nullpointer in a multi-threaded app that does
quite a bit of snmp.    I may have nailed down my original problem but I
also saw this snippet of code in the transmitter and I'm hoping someone can
put me at ease that the nullpointer couldn't come from here:
 
 
    /**
     * This method is the counterpart of sit().
     *
     * The Pdu will call this method when it is sent.
     * This method will notify itself and in the end it is transmitted
     * in run.
     *
     * @see #sit()
     * @see #run()
     * @see Pdu#send
     */
    synchronized void stand()
    {
        notifyAll();
    }
 
    /**
     * It may be sleeping (as opposed to wait()ing
     * so send it a kick.
     */
    void interruptMe()
    {
        // unsafe ?
        me.interrupt();
    }
 
    void destroy()
    {
        me = null;
        pdu=null;
        stand();
    }
 
 
When context.destroy() is called it calls destroy on the transmitters ( by
actually calling the freetransmitters method).     My thought is this:  If a
trnasmitter is "sit" and a destroy comes in, it will set "me = null".   What
if a latent host reponds at that moment?   It would call pdufillin which in
turn would call interuptMe() - however since "me" is null courtesy of the
non synchronized destroy then you would get a nullpointer from
"me.interrupt()"
 
 
I know it sounds a long shot but when you are running 99 major threads, each
running 3 discovery subthreads across 65k - 16Million addresses the
statistically improbable can happen.   
 
 
 
If I'm in any way correct about this could the following changes alleviate
the risk?
 
destroy calls interruptMe() first and THEN sets me = null   ?
 
 
Synchronizing destroy in the past led to some stack deadlocks so I'm
avoiding that as a suggestion.