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

Groups > comp.arch.embedded > #12878

Re: Resource revocation

Cross-posted to 2 groups.

Show all headers | View raw

Greetings, Boudewijn!

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!

"Service" can perform neither client1 nor client2's actions with
that resource -- doing so would require intimate knowledge of their
respective applications.

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

How long do you allow the current user to hold onto the resource
after notification that it MUST be relinquished?  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.)

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.

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

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!")]

>> When done, they surrender the resource to the service where
>> it can be reused by other consumers.
>>
>> But, there are times when the service must revoke a granted
>> use of a particular resource.  In some cases, it "asks" for
>> the resource back (giving the current consumer time to
>> tidy up before releasing it).  In other cases, it just *seizes*
>> the resource -- and notifies the consumer after-the-fact.
>
> What if:
> Scenario B
> 1. client sends request to server for an "action"
> 2. server checks for incoming requests
> 3. server starts work on action
> 4. server decides to interrupt the action
> 5. server notifies client of non-completion

See above.  Server is just metering out resources so the only
"action" it can provide is granting or denying access to that
resource.

>> Presently, I use signals to notify the consumer when this
>> sort of thing is happening.
>
> I always found the POSIX signal interface awkward for anything but
> IRQ-type things.

But that's how I see these things.  In much the same way
that a scheduler invocation INTERRUPTS a currently executing
task's access to the "CPU".

The difference is the interrupted task has a contract with the
scheduler that it will *try* to resume the task WHERE IT LEFT
OFF at some later point in time.  AS IF, the interrupt had
never happened (unless the task is actually watching the
wall clock or anything else that changes with the passage of
REAL time!).  I.e., the task is not asked for it's *consent*
to be interrupted -- even if it might never be resumed!

Similarly, a task can be killed asynchronously.  There is no
prerequisite to notify it, in advance (pre-notification can
make its shutdown more orderly -- but, also requires more
elapsed time *and* coding!)

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

Or, whose messages/replies aren't being delivered due to
network congestion, delays, etc.  (uniprocessor and SMP
techniques don't map directly into the distributed world
where these guarantees are a lot harder to meet *in* a
timeliness context!)

[Remember, a message has to get from its originator, through
that scheduler (i.e., when is the originator allowed to execute?),
through the network stack (is it an RT stack??), onto the media
up through the receiving stack (again, RT?) and dispatched to
a task running at some unknown LOCAL priority before that task
can even *see* it.]

By contrast, notification (e.g., signal) that the resource has
ALREADY been revoked has an implicit "fait accompli" -- regardless
of how long the message took to transit.

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

>> 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!  :-/

--don

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

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