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

Groups > comp.arch.embedded > #26405

Re: Dynamic upgrading/Hot-swapping a service

Show all headers | View raw

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

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

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