Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #12896
| From | "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> |
|---|---|
| Newsgroups | comp.arch.embedded, comp.realtime |
| Subject | Re: Resource revocation |
| Date | 2013-08-01 14:42 +0200 |
| Organization | Indes - IDS B.V. |
| Message-ID | <op.w041ln0tj0diun@thanatos.indes.com> (permalink) |
| References | <ksrtvv$kmp$1@speranza.aioe.org> <op.w02339yij0diun@thanatos.indes.com> <ktb89p$fei$1@speranza.aioe.org> |
Cross-posted to 2 groups.
Op Wed, 31 Jul 2013 16:51:38 +0200 schreef Don Y <this@isnotme.com>:
> On 7/31/2013 4:41 AM, Boudewijn Dijkstra wrote:
>> Op Thu, 25 Jul 2013 21:23:46 +0200 schreef Don Y <this@isnotme.com>:
>>> What's the current "best practices" regarding asynchronous
>>> notifications (in a multithreaded environment)?
>>
>> One such practice is asynchronous direct message passing.
>>
>>> I have a system wherein "tasks" (omit a formal definition)
>>> request resources from a service that meters out their use;
>>> waiting until the resource has been granted to them
>>> "officially" (in some cases, this is all trust based).
>>
>> Is it really necessary for the resource to be granted, or can the
>> service keep the resource and use it on behalf of the client tasks,
>> passing messages as necessary?
>>
>> Scenario A
>> 1. client sends request to server for an "action"
>> 2. server checks for incoming requests
>> 3. server starts work on action
>> 4. server completes action
>> 5. server notifies client of completion
>>
>> Note that the client might do other things while the server is busy, or
>> wait for the server reply.
>
> 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".
> "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.
> 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.
> 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.
> 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).
> [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.
> 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.
> [...]
>
>>> But, my personal experience is such that folks have problems
>>> writing this sort of code. *Remembering* that they have to
>>> register a handler for the signal; remembering that said
>>> handler can be invoked at any time (including immediately
>>> after it has been registered); etc.
>>
>> Perhaps the real problem is the lack of a functional and intuitive
>> interface. A good message passing interface allows you to know which
>> tasks are not handling their incoming messages.
>
> [...]
>
> 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.
>>> Is there a new "safer" way of implementing these types of
>>> notifications?
>
> I'm willing to live with signals *if* I can come up with a
> clean framework that makes it easy for developers to implement
> them, correctly. (so a client isn't chugging along in ignorance
> thinking that it still owns that resource that has ALREADY been
> revoked and repurposed).
>
> [E.g., you *think* you are watering the yard but, in fact, there
> is no water flowing through *your* pipes! Or, you *think*
> a CPU is busy working on some aspect of your "job" but it has
> been reallocated to some other purpose... you'll be waiting
> *forever* for it to complete!]
>
> Yet another example of how bending requires more thought/work
> than simply throwing excess capacity at a problem! :-/
Indeed.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
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