On 4/24/2017 15:33, Don Y wrote:
> On 4/24/2017 7:48 AM, Phil Martel wrote:
>>>>>> I still do not see what your actual problem is.
>>>>>
>>>>> Find a piece of software that is currently executing: your
>>>>> microwave oven controller, your PC (consider it a *collection*
>>>>> of software), your calculator, your ....
>>>>>
>>>>> Now, WHILE it is "solving some particular problem for which it
>>>>> was designed", pause the clock and replace all the INSTRUCTIONS
>>>>> in the program(s) with a new, revised program (it does <whatever>
>>>>> only "better" (the 8 digit calculator now handles 12 digits; the
>>>>> microwave oven now has 6 other types of cycles; the PC is now
>>>>> running Windows 11 instead of DOS 3.3; etc.)
>>>>>
>>>>> Let the clock resume. None of the actions that were running
>>>>> at the time the clock was PAUSED should have been affected by
>>>>> the upgrade. I.e., if the calculator was in the middle of
>>>>> computing "14!", it should continue to completion -- from
>>>>> wherever it happened to have been, at the time -- yielding
>>>>> the correct result.
>>>>>
>>>>> Note, however, that the result should now be displayed as
>>>>> 8.71782912*10^10 or 87178291200 and NOT as 8.7178291*10^10
>>>>> to reflect the extra precision that it has internally
>>>>> as well as the extended "display"/reporting capability
>>>>> (assuming, of course, that the original executable was
>>>>> interrupted before any loss of precision).
>>>> Since this group is for embedded processing, it is fair to ask why the
>>>> original
>>>> calculator would have a display with more that 8 significant figures.
>>>
>>> Why does the calculator *function* have to be implemented in
>>> a calculator *package*? Do you not use <math.h> in your
>>> embedded applications?
>>
>> Obviously it doesn't have to be, but it may be. Perhaps "calculator"
>> is a poor
>> example of what you're trying to explain
>
> I'm trying to pick examples of "programs" that people can easily
> understand. A calculator evaluating a transcendental function
> (i.e., something with some "meat" in it) could approach the
> problem in different ways (Taylor series, CORDIC, etc.) in
> different "revisions"/versions.
>
> So, (*ignoring* the desire to upgrade due to a *flaw* in the
> implementation,) it is conceivable that you would want to
> upgrade the algorithm to adopt an approach that converges
> more quickly.
>
> And, because the algorithm would be iterative, it is likely
> that it could be "in progress" when you choose to upgrade the
> software (e.g., an 80b floating-point "FMUL" can be a single
> instruction but FTANH probably isn't!).
>
> Finally, the approaches can vary significantly in terms of
> their resource requirements (e.g., temporary storage) making
> a direct mapping of one to the other virtually impossible.
>
>>>>> Put something in your microwave oven. Set the timer to X.
>>>>> After an arbitrary amount of time, pause the process (processor)
>>>>> and replace the ROMs. Resume the process. EXPECT the entire
>>>>> process -- start to finish -- to proceed exactly as it would
>>>>> have had you not replaced the ROMs!
>>>> This assumes that you can replace the ROMs by some hot-swap process
>>>> that does
>>>> not kill power to the RAM/registers that hold the state and quickly
>>>> enough that
>>>> the food will not cool substantially.
>>>
>>> Again, imagination suggests you could implement the ROMs (i.e., the
>>> program TEXT) in other media that *can* be (effectively) replaced
>>> "between
>>> one clock cycle and the next". This is all old technology. The problem
>>> lies in doing so while some consumer (client) might be ACTIVELY
>>> executing
>>> within that block of program TEXT.
>>
>> I'm not familiar with *how* these systems do what they do. Keeping
>> the old
>> copy running while clients are in the middle of a transaction and perhaps
>> warning them to finish up is an option.
>
> That assumes they *will* "finish up" (consider a "black box" service that
> is always receiving "log" information) and in the time frame that *you*
> consider appropriate. If you're shutting down a node in a cluster for
> periodic maintenance, you can probably afford to wait seconds/minutes
> for everything to come to an orderly state. But, you can't make that
> generalization about all clients and dependencies (recall, many clients
> are, typically, *agents* -- "serving" clients of their own!)
>
> You can always ensure no *new* clients avail themselves of the "old"
> instance of the service thereby (hopefully) expediting its "release".
>
>>>> Also, the old program state must be
>>>> coded so that the new ROMs read and operate on it properly.
>>>
>>> No, that isn't necessary. In fact, different algorithms may use
>>> inconsistent state vectors so that mapping from one algorithm to
>>> another is not possible. That doesn't preclude "interrupting"
>>> existing processing, replacing the TEXT and finishing the
>>> processing with the "new" algorithm.
>>
>> Provided you translate and replace the existing state vector also.
>
> That may not be practical.
>
> factorial(n: int) : int
> ASSERT( n >= 1 )
> result := 1
> while (n > 1) {
> result *= n
> n--
> }
> return result
> }
>
> factorial(n: int) : int
> ASSERT( n >= 1 )
> if (n == 1)
> return 1
> return N * factorial(n-1)
> )
>
> have vastly different state vectors (assuming I haven't botched the
> implementations).
>
> So, just assuming you can <somehow> map one state vector into another
> won't give you a "fix".
So, lets say you're in the middle of calculating
factorial(1,000,000,000,000) with algorithm 2. Then you find out about
algorithm 1 (or maybe decide that Stirling's approximation is close
enough). What *can* you do with the unfinished solution other than dump
the work and restart the problem with the new algorithm or let it
finish? (and next time use the new algorithm)?
>
>>>> It sounds like a lot of work.
>>>
>>> That's why things like Windows want you to reboot so often! :>
>>>
>>> OTOH, web sites and enterprise systems regularly roll out
>>> updates WHILE still providing services -- because the cost
>>> of shutting the systems/services down for that update can
>>> be substantial ("We're sorry, but the on-line banking transaction
>>> that you are engaged in AT THIS MOMENT will be aborted. Please
>>> try again later.")
>>
>> I'm not familiar with *how* these systems do what they do. Keeping
>> the old
>> copy running while clients are in the middle of a transaction and perhaps
>> warning them to finish up is an option.
>
> I think most of these types of services are short-lived and/or
> transactional. And, for services with human interaction, you can
> always hope the human "client" is "understanding"/patient (which
> is possible IF these types of inconveniences aren't frequent)
>
>>> (Would you want to have to *stop* your car to have the code in the
>>> ABS system updated -- given that stopping the car might not be
>>> possible, reliably, given the current state of the ABS code? :> )
>>
>> Would you want to rely on the company that wrote the bad ABS code to
>> fix it and
>> do so while your car was moving? I suspect that the "fix it live"
>> problem is
>> tougher that the "ABS" problem.
>
> *Undoubtedly* tougher! OTOH, if there was sufficient risk (death or
> injury)
> to applying the brakes *prior to* installing the upgrade, I'd much prefer
> <someone> invest in *that* solution! You can't tell the Apollo 13 crew
> that you'll fix their problem -- AFTER they return home... :>
>
>> FILAAS (Fix it live as a service) might be possible if the processor
>> and system
>> the ABS was running on was standard, but what about your cardiac
>> pacemaker? Is
>> that running on the same processor?
>
> Pacemaker is a perfect example of upgrade /in situ/. Of course, the
> chances
> of the pacemaker needing to perform its function during the upgrade AND
> being
> unable to do so AND the patient dying while the doctor is standing
> nearby is
> probably pretty slim. And, the pace maker designer undoubtedly considered
> this capability in their design of the product.
>
> We worked out a bunch of different approaches to the problem Friday night.
> Unfortunately, no *one* is a panacea. So, I'm working through the costs
> (and consequences) of each approach. I've got an off-site/retreat coming
> up RSN so I hope to bring my problem to the table, there.
>
> As I can't rely on others (writing code to run in my system) to design
> components with this capability in mind, I need a fall-back strategy that
> will allow me to upgrade *those* components in the least painful way
> possible
> (if those folks' products end up "looking bad" as a result, its their
> "image"
> to attend to).
--
Best wishes,
--Phil
pomartel At Comcast(ignore_this) dot net