Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26404

Re: Dynamic upgrading/Hot-swapping a service

Show all headers | View raw

On 4/23/2017 13:52, Don Y wrote:
> On 4/23/2017 10:01 AM, Phil Martel wrote:
>> On 4/22/2017 11:55, Don Y wrote:
>>> On 4/22/2017 4:09 AM, upsidedown@downunder.com 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

> With the tiniest bit of imagination, one should be able to consider
> a new math library that had greater precision *or* different
> algorithms that converged faster than the previous implementation.
>
> Given that you (I) can not shut the application down "for
> maintenance", how would you replace the library (used by multiple
> modules) in the application while the system was powered up and
> operating?   (see my previous examples for steps)
>
> Replace "library" with "service" and you have my original question
> (i.e., most libraries can be implemented *as* services with the
> re-formalization of the interface communication overhead)
>
>>> 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.

>> 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.

>> 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.
>
> (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.

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?

-- 
Best wishes,
--Phil
pomartel At Comcast(ignore_this) dot net

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-20 16:05 -0700
  Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-20 16:11 -0700
  Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-21 10:45 +0300
    Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-21 10:43 -0700
      Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-21 23:06 +0300
        Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-21 17:51 -0700
          Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-22 14:09 +0300
            Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-22 08:55 -0700
              Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-23 13:01 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-23 10:52 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-24 10:48 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-24 12:33 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-24 22:02 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-24 21:37 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-25 12:19 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-25 13:54 -0700

csiph-web