<div dir="ltr">I haven't looked at this code before, but in looking now, I am confused.<div>Interpreter is intended to be a singleton, right? (that's what the comment says, as well as what is suggested by the use of the static interpreter variable.).</div><div>In that case why would you want to createInstance to ever return null? </div><div>Why isn't there just a single synchronized getSingleton() (call it getInterpreter if you want) method, which either returns returns the existing interpreter, or creates and initializes a new one and returns it.</div><div><br></div><div>Alan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 1:06 PM Mark Evenson <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Mar 11, 2019, at 16:18, Pascal Bourguignon <<a href="mailto:pjb@informatimago.com" target="_blank">pjb@informatimago.com</a>> wrote:<br>
> <br>
> <br>
> <br>
>> On 11 Mar 2019, at 10:59, Mark Evenson <<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>> wrote:<br>
>> <br>
>> <br>
>> <br>
>>> On Mar 11, 2019, at 06:38, dingd <<a href="mailto:ntysdd@qq.com" target="_blank">ntysdd@qq.com</a>> wrote:<br>
>>> <br>
>>> this is recommended in the manual, it contains a race condition.<br>
>>> <br>
>>> Interpreter interpreter = Interpreter.getInstance ();<br>
>>> if ( interpreter == null ) {<br>
>>>     interpreter = Interpreter.createInstance ();<br>
>>> }<br>
>>> <br>
>>> getInstance and createInstance should be swapped.<br>
>> <br>
>> Since both Interpreter.getInstance() and Interpreter.createInstance() are<br>
>> methods synchronized on the same object monitor, I don’t see that there is a<br>
>> race condition here.  Could you explain a little more about your reasoning<br>
>> and/or experience with the race condition?<br>
> <br>
> <br>
> Two threads could call getInstance and have interpreter=null.<br>
> Then both will call createInstance, thus two instances will be created.<br>
> If interpreter is a local binding as it appears in the code above, then it is what’s intended and all is good.<br>
> But if interpreter is a global binding and you expected interpreter to have a single instance, then it’s wrong.<br>
<br>
I am not sure what you mean by global/local bindings here, as these concepts<br>
don’t exist in Java as far as I know,  but I think dingd is correct here:  I<br>
don’t think two instances of the interpreter will be created.<br>
<br>
As the Interpreter.createInstance() is synchronized on the Interpreter class<br>
(the “object monitor”), one of the calls to createInstance() will succeed in<br>
creating a value in the static Interpreter.interpreter reference, while the<br>
other will return null.<br>
<br>
<br>
 // Interface.<br>
    public static synchronized Interpreter createInstance()<br>
    {<br>
        if (interpreter != null)<br>
            return null;<br>
        interpreter = new Interpreter();<br>
        _NOINFORM_.setSymbolValue(T);<br>
        initializeLisp();<br>
        return interpreter;<br>
    }<br>
<br>
I’m still scratching my head over why the current implementation is so<br>
convoluted.   Part of the problem is that we have three methods of creating an<br>
interpreter namely, createInstance(), createDefaultInstance() and<br>
createJLispInstance() with two different possible private constructors.  If<br>
anyone has a good handle on the right architecture here, please pipe up.  <br>
<br>
The simplest path forward would be to change the documentation, as dingd<br>
originally suggested.  But that path isn’t very satisfying. <br>
<br>
<br>
-- <br>
"A screaming comes across the sky.  It has happened before but there is nothing <br>
to compare to it now."<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>