Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #12898
| From | Don Y <this@isnotme.com> |
|---|---|
| Newsgroups | comp.arch.embedded, comp.realtime |
| Subject | Re: Resource revocation |
| Date | 2013-08-01 14:34 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <ktek9d$818$1@speranza.aioe.org> (permalink) |
| References | <ksrtvv$kmp$1@speranza.aioe.org> <op.w02339yij0diun@thanatos.indes.com> <ktb89p$fei$1@speranza.aioe.org> <op.w041ln0tj0diun@thanatos.indes.com> |
Cross-posted to 2 groups.
Hi Boudewijn,
On 8/1/2013 5:42 AM, Boudewijn Dijkstra wrote:
>> In my cases, services are often physical ("real world") resources.
>> E.g., client1 would like to use water (at a certain rate of flow)
>> to irrigate some portion of the landscape. Service grants this
>> request. Some time later -- before client1 has finished using
>> the resource -- client2 would like to use water to "take a shower".
>>
>> The service knows (because of codified rules) that taking a shower
>> is a higher priority (in terms of "importance") than watering
>> the yard (because the system has defined it to be so!). In an
>> ideal world, service could notify client1 and *command* that it
>> release the resource, "now". Await acknowledgement that it has
>> released the resource, then grant it to client2. Presumably,
>> client1 will immediately issue a request for the resource -- which
>> the service will defer -- because client2 is now using it and has
>> a higher priority (think preemption) than client1!
>
> Why be so nice? Surely most clients are perfectly OK with getting cut
> off "now" and receiving a notification "circa now".
Well, to cover the widest class of apps and implementations, it
would be nice to be able to receive notification so you could
do any cleanup, etc. E.g., if the resource was "primary power",
you might want to spin down any mechanisms that are currently
in motion before the power is forcibly removed.
For a compute resource, you might like to be able to checkpoint
its progress instead of losing ALL of its state when it is
KILL'ed. Etc.
At the other end of the spectrum are some of the cases I illustrated.
E.g., you *have* to be able to cope with a loss of power, water,
etc. -- whatever the resource -- because the system itself has no
guarantees that these resources will be available for its own use!
(i.e., if you can't handle losing power asynchronously, how will
you handle a REAL power outage/"blackout"?)
>> "Service" can perform neither client1 nor client2's actions with
>> that resource -- doing so would require intimate knowledge of their
>> respective applications.
>
> In this case I'd say the action is "deliver water", and requests could
> specify a definite amount of water or time, or leave it undefined.
Yes, but that's a trivial case (and, if you look at my followup
where I qualify how I actually manage "water" with a "trusted"
intermediary, you can see that this is how things work AT ONE
LEVEL in that particular application).
OTOH, imagine the resource is computational. Or, associated with
some particular I/O device that isn't directly attached ("serviced")
by the "server" (e.g., a persistent data store). The server may
not *have* the resource to be able to *supply* it. E.g., the
workload manager doesn't have gobs of spare MIPS. Rather, it keeps
track of where excess capacity exists in the system and allows
clients to avail themselves of that capacity (resource) -- based
on *its* metering of the resource.
>> The flaw in this "cooperative" approach is client1 need not comply
>> with that "command". Or, might be sluggish in complying. Then,
>> client2 sees an artificial delay in when it can legitimately use
>> the resource. Similarly, it might be reluctant to relinquish it
>> when the fire suppression system client *needs* it. (i.e., these
>> are all just different "priorities"/importances to the service.)
>
> Normally fire suppression is more important than any damage caused from
> taking the resource by force.
Yes. But you could pick other pairs of uses and get different results
(e.g., the ACbrrrr vs. kiln, below)
>> How long do you allow the current user to hold onto the resource
>> after notification that it MUST be relinquished?
>
> Before any HRT deadline, I suppose.
(Ignoring S/H issues...) but the task being *asked*/commanded to
release the resource has no knowledge of the deadlines (priority,
importance, etc) of the prospective new consumer of that resource!
Nor should it! (?)
I.e., a preemptive scheduler (anything beyond a simple RR) embodies
the knowledge of priorities, deadlines, etc. in a system -- not the
tasks themselves. Hence, we don't *ask* a task to yield the CPU;
we just *take* it. And the tasks know that this is a condition of
their execution (in this environment).
For a client to know that it must release a particular *use* of a
particular resource in a specific time, it would need to understand
other aspects of the system beyond its own (e.g., the requirements
of the client that will NEXT be using this resource).
>> What if your
>> message got lost on the network -- does your protocol include
>> time for a reissued "command" to be delivered SO client1 CAN
>> COOPERATIVELY RELINQUISH THE RESOURCE? What happens *in*
>> client1 when it "discovers" the resource has been withdrawn?
>>
>> (I.e., I contend client1 has to be able to handle the asynchronous
>> revocation of the resource *without* notification, regardless.)
>
> Absolutely.
>
>> So, you have to implement a fail-safe mechanism whereby you can
>> forcibly revoke the service from a noncompliant client -- and
>> deal with the consequences of that.
>
> Or forcibly revoke by default and allow clients to indicate whether
> they'd like an advance warning (which is not guaranteed to be timely in
> case of network hiccups).
But, this means every service (or agency) has to support both
options: unceremoniously revoke a resource that it wants/needs
to dole out to another client/consumer *plus* provide advance
warning (and somehow fold notification of the timeliness
constraints for *this* revocation into that notification) if the
client so desires.
I.e., instead of "burdening" the client with being able to
*just* handle the asynchronous notification of a resource's
revocation, you now require all services/agencies to implement
both capabilities!
(Note that an "app" can just as easily be a "client" or a
"service"/agency! So, now there is even more you have to
hope the developer "gets right")
One possible approach would be to allow the service to advertise
it's "revocation policy". (e.g., "I do not provide advanced
warning of revocation"; "I will provide advanced warning -- within
some limits that I might not to advertise, here"; "I will never
asynchronously revoke a granted resource"; etc.) And/or allow
clients to condition their acceptances of a resource (e.g.,
"I want this resource but only if you will provide me XXX prior
notification of its future revocation"; "I want this resource but
only if you can guarantee it to me for <some_criteria>"; etc.)
[This can quickly get unwieldy -- though you could build a
library/service to manage this sort of thing in a reliable
manner ON BEHALF OF other services!]
>> [For other examples, consider a client that wants to operate the
>> air conditioner compressor while another has already been granted
>> use of a certain amount of AC power for the electrically fired
>> kiln. While air conditioning seems like it should be a high
>> priority/importance task, turning off the kiln before the glaze
>> is completely baked will probably alter the appearance of the
>> piece -- possibly rendering the work "useless" (along with all
>> of the electricity expended to bring it to that point).
>
> So airco has high priority and kiln has low priority initially, but
> changes to critical priority once baking has started. (Which is still
> below emergency priority.) If you were illustrating a problem, I don't
> see it.
If you embody "policy" in the service provider (i.e., let *it*
decide how it can forcibly revoke previously granted resources),
how much of the details of a particular consumer's use of that
resource does it need to be aware of? How do you allow for the
introduction of new knowledge as new consumers are developed
or brought on-line?
I.e. you *really* would like the client to have some influence
over this policy (future-safe). Yet, at the same time, you don't
trust him to be impartial in this voice!
"Oh, it's REALLY REALLY REALLY important that I never be denied
access to a resource! I am SUPER IMPORTANT. Trust Me. You
have my word on it. -- Joe Isuzu"
[Forgive the cultural reference]
>> Or, imagine the resource is the MIPS available on some processor
>> that is underutilized in the system. Or, some portion (KB/MB)
>> of a fixed size, persistent store ("Yeah, I know you'd love to
>> store your children's birthdates. And, I know we told you,
>> previously, that you could use this space for that. But, we
>> *really* need to store this critical log message until someone
>> has a chance to review it!")]
>
> In these cases the clients need to be able to detect the availability of
> the resource, either via a guaranteed notification or some other sense.
It's available when it was (past tense) granted to the client.
And, the client went on its merry way "knowing" that it owned
that resource.
Now, later, you change your mind and revoke that resource
(possibly without any forewarning -- the client might NOT
have a "local copy" to fall back on, etc.)
[I'm just trying to illustrate the different ways *each*
approach can screw you]
>> Neither is a particularly great way of dealing with the problem.
>> But, cooperation just seems to rife for abuse. Even well-intentioned
>> clients might be busy when the request (command) arrives. And,
>> may have complex requirements to wind down their use of that
>> resource in a timely fashion E.g., they might be acting as an
>> agent/server for some related "resource" that some *other* client
>> is currently using. And, that client will need to be "notified"
>> that it must release that resource... before the original client
>> can release the resource it has been commanded to release.
>>
>> (How long do you sit patiently -- defering the needs of that
>> original client2 -- while you try to be polite/accommodating
>> of client1 et al.?)
>
> It all depends on how damaging each decision is. In case of water or
> electric power the clients might detect when the resource is going away.
> They might have an internal buffer for winding down or they might have a
> special procedure in case of immediate cut-off.
Yes, but deciding what the current "consequences/priorities/importances"
of a given resource assignment gets tricky. Do you put all of the
decision in the service/agency (i.e., the mechanism that is doling
out the resource(s))? Leave it up to the consumers to *declare*
(and.or implement their requirement constraints)? Or, some combination
of the two?
E.g., in a trusted environment, you can freely share this responsibility
so that you better find the performance/reliability "sweet spot" for
a given set of resources and consumers.
But, when you don't inherently trust a consumer to "be fair", it
gets much more difficult.
And, I haven't even addressed things like potential for deadlock!
I.e., how do you implement a "safe" mechanism ACROSS A VARIETY
OF SERVICES implemented on numerous different servers to ensure
"tasks" (which may be consumers and producers) don't get into
deadlock WITHOUT KNOWLEDGE OF OTHER tasks in the system?
<frown> There just doesn't seem to be much prior art to address this
sort of issue... And, the size/distributed nature just makes it
that much more difficult to "nail down" systemically.
--don
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Resource revocation Don Y <this@isnotme.com> - 2013-07-25 12:23 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 12:51 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 15:00 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 19:38 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 22:12 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 23:37 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 01:13 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 02:48 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 04:19 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 09:46 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 10:21 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:30 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 11:56 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 20:08 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 13:11 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 12:31 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 11:08 -0700
Re: Resource revocation Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-07-29 09:16 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 10:22 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 11:22 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 08:56 -0700
Re: Resource revocation Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-07-26 19:25 +0200
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 10:51 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:21 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 11:50 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:42 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:43 -0700
Does the Buddha have a real time nature? ;) (was Resource revocation) Roberto Waltman <usenet@rwaltman.com> - 2013-07-26 17:06 -0400
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Don Y <this@isnotme.com> - 2013-07-26 17:12 -0700
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 09:44 +0100
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 09:45 +0100
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Don Y <this@isnotme.com> - 2013-07-27 12:28 -0700
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-07-27 14:11 +0200
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:40 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 21:29 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 13:52 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 22:55 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 17:22 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 10:02 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 09:29 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 18:20 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 12:48 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 22:57 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:18 -0700
Re: Resource revocation Roberto Waltman <usenet@rwaltman.com> - 2013-07-31 16:33 -0400
Re: Resource revocation upsidedown@downunder.com - 2013-07-27 22:53 +0300
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 22:42 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:41 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:49 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-28 08:39 +0300
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 23:11 -0700
Re: Resource revocation Roberto Waltman <usenet@rwaltman.com> - 2013-07-31 16:15 -0400
Re: Resource revocation upsidedown@downunder.com - 2013-08-01 00:13 +0300
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:16 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:05 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:37 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:38 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 16:08 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-28 01:16 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 18:43 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-28 09:01 +0300
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:21 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:07 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:00 -0700
Re: Resource revocation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-27 16:49 +0000
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-28 18:31 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-28 15:51 -0700
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-28 20:12 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-28 18:35 -0700
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-29 00:10 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 00:23 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 01:05 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 12:07 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-30 01:11 +0300
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 15:20 -0700
Re: Resource revocation Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-07-29 15:42 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 16:41 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-30 08:51 +0300
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 09:09 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 01:30 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 10:04 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 02:55 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 07:12 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 16:59 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 13:17 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 10:12 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 18:48 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 20:18 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-31 09:27 +0300
Re: Resource revocation [long] Don Y <this@isnotme.com> - 2013-07-31 00:47 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 02:50 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-30 13:22 +0300
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 07:24 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 01:17 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 19:28 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-29 11:40 +0300
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 11:44 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-29 20:56 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 13:16 -0700
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-30 00:08 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 23:41 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-31 00:58 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-31 10:18 -0700
Re: Resource revocation George Neuner <gneuner2@comcast.net> - 2013-08-02 06:19 -0400
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-08-03 02:26 -0400
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-28 19:31 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 00:44 -0700
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-25 22:42 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 22:12 -0700
Re: Resource revocation "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2013-07-31 13:41 +0200
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 07:51 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 08:07 -0700
Re: Resource revocation Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-07-31 15:55 +0000
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 10:18 -0700
Re: Resource revocation "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2013-08-01 14:42 +0200
Re: Resource revocation Don Y <this@isnotme.com> - 2013-08-01 14:34 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-08-02 09:08 +0300
Re: Resource revocation Don Y <this@isnotme.com> - 2013-08-02 07:26 -0700
csiph-web