An update to this subject thread:

It appears a VERY subtle problem (at least for the engineers working this 
problem) concerning the scheduling of null messages is responsible.  This 
ordering, it turns out, is (now was) effected by the order in which LP's are 
started and this doesn't manifest itself for some time in the execution.  So 
to sum things up:

Squeak is NOT the source of the problem, the software engineers writing the 
code are - MEA CULPA!


Thanks for ALL the help!
Elzbieta



>===== Original Message From Yanni Jew <yanni at home.com> =====
>My gut feeling is that there is a timing problem.
>Once you add the "halt" or debug code, it delays
>execution long enough that the execution order works.
>Without the delay, you end up hitting the execution
>order which doesn't work.
>
>I'd look into the communication code you're using
>to send events between your "logical processes" (images).
>If possible, without disturbing the execution too much,
>try to insert code that gets you a trace of the execution
>sequence. Then compare the "good" sequence with the "bad".
>You probably want to collect the events for later analysis,
>since writing them to the Transcript or to a file may
>cause enough delay to mask your timing problem.
>
>--yanni
>
>Bert Freudenberg wrote:
>>
>> I'm fowarding this to the list so someone more experienced with processes
>> hopefully can answer it.
>>
>> -- Bert
>>
>> ---------- Forwarded message ----------
>> Date: Sat, 3 Mar 2001 12:28:05 -0500
>> From: Elzbieta Chludzinska <elzbieta at operamail.com>
>> To: Bert Freudenberg <bert at isg.cs.uni-magdeburg.de>
>> Subject: RE: [PROBLEM] code generation & processes???
>>
>> Our mail server has had some problems lately, so I don't know if this got
>> through and I'm re-sending it! ---Elzbieta
>>
>> Bert,
>>
>> First of all, DANKE!
>>
>> I'm working on a parallel sim wargame using what is called conservative 
time
>> synchronization.  The algorithm is a modified Chandy-Misra-Bryant algorithm
>> and it depends on the sending of null messages (events) to keep the 
"logical
>> processes" (LP) synchronized - in Smalltalk/Squeak each LP corresponds to 
an
>> image.
>>
>> When I experience this "phenomena" (problem) NONE of the LP's advances in 
time
>> - they stop executing events.  If I try using "self halt" to debug, the 
LP's
>> proceed to advance their clocks - execute events. If I try adding debugging
>> code, again the LP's start executing events.
>>
>> It's a little like quantum mechanics - I can't observe the "process" 
without
>> effecting the results.  If you have ANY suggestions - I'M LISTENING! I've
>> tried playing with the priorities of the 3 Processes running in each image 
but
>> to no avail.  How could moving what is in essence a no-op statement change 
the
>> behavior of the processes?
>>
>> DANKE! - DZIEKUJE!
>>
>> Elzbieta
>>
>> >===== Original Message From Bert Freudenberg 
<bert at isg.cs.uni-magdeburg.de>
>>     =====
>> >On Fri, 2 Mar 2001, Elzbieta Chludzinska wrote:
>> >
>> >> The #send:to: places the null event (after it's been packed into
>> >> ByteArray) on a SharedQueue.  The packed null event is taken off the
>> >> instance of SharedQueue by another Process which sends it to the other
>> >> image.
>> >
>> >What does it do when it fails?
>> >
>> >-- Bert
>>
>>  Click here to enter secure mode.
>> Powered by Infinite Inter
>>
>> >===== Original Message From Bert Freudenberg 
<bert at isg.cs.uni-magdeburg.de>
>> =====
>> >On Fri, 2 Mar 2001, Elzbieta Chludzinska wrote:
>> >
>> >> The #send:to: places the null event (after it's been packed into
>> >> ByteArray) on a SharedQueue.  The packed null event is taken off the
>> >> instance of SharedQueue by another Process which sends it to the other
>> >> image.
>> >
>> >What does it do when it fails?
>> >
>> >-- Bert