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

Groups > comp.arch.embedded > #12715

Re: Resource revocation

From Don Y <this@isnotme.com>
Newsgroups comp.arch.embedded, comp.realtime
Subject Re: Resource revocation
Date 2013-07-25 22:12 -0700
Organization Aioe.org NNTP Server
Message-ID <kst0fc$208$1@speranza.aioe.org> (permalink)
References <ksrtvv$kmp$1@speranza.aioe.org> <CmlIt.172003$zH4.137877@en-nntp-14.dc1.easynews.com>

Cross-posted to 2 groups.

Show all headers | View raw

Hi Richard,

On 7/25/2013 7:42 PM, Richard Damon wrote:
> On 7/25/13 3:23 PM, Don Y wrote:

>> What's the current "best practices" regarding asynchronous
>> notifications (in a multithreaded environment)?
>>
>> 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).
>>
>> 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.
>>
>> Presently, I use signals to notify the consumer when this
>> sort of thing is happening.
>>
>> 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.
>>
>> Is there a new "safer" way of implementing these types of
>> notifications?
>>
>> Thx,
>> --don
>
> My first thought about your seizing mechanism is that you are going to
> need to either kill the task you granted the permission to, or tolerate
> it using the resource after you have seized it (perhaps with some error
> occurring on the use).

Or, let the task *think* it is still using the resource even though
its actions on/with that resource aren't having the effects the
task *thinks* they are having!

I.e., it depends on what that "resource" is and how it is accessed.

If, for example, it is a (shared) communication channel, the task
can *think* it still has (exclusive?) use of the channel but the
mechanism that actually pushes messages onto/from the channel is
actually silently discarding everything to/from the task when it
no longer *owns* the resources (while the actions of the NEW owner
are now proceeding properly).

If the resource is a piece of virtual memory, the OS can allow
accesses to continue (without faulting) and just ignore all the
writes attempted and return garbage for reads.

Or, these "uses while not currently owned" could result in errors
reported to the user -- that may or may not be expressly indicative
of the fact that the resource is no longer owned.  E.g., "read failure"
and the task scratches its head wondering if the medium is faulty
or <whatever>.

There's also the (un-illustrated) example of the task actually
being *allowed* to continue using the resource under the assumption
that it will, in fact, "soon"  honor the *request* that it release
the resource.  ("Gimme a minute...")

Remember, a "resource" is anything that the system *decides* is a
resource.  and, asynchronous notifications can originate for a
variety of *other* reasons in addition to resource revocation.

The "resource" that prompted my question is an abstract resource
with very loose constraints -- and, no real downside to having it
revoked "in use".  I was coding an algorithm for an irrigation
"zone" wherein the process responsible for the zone *requests*
a certain "water flow rate" (water being the scarce resource and
it is infinitely divisible).

The task can't begin monitoring the amount of water dispensed
for its needs until it knows that water *is* being dispensed
for its needs.  ("OK, 1 gallon per minute so I need to wait
14.34 minutes to ensure the required 14.34 gallons are dispensed.
THEN, I can turn off the water and let the system use it for
some other purpose.  Shower, anyone??")

Delays in acquiring the resource have consequences (i.e., the
task doesn't just want to *block* awaiting it) since an indefinite
delay means the zone never gets serviced (things die, etc.).  So,
the task (or a surrogate operating on its behalf) needs to be
able to watch (and worry!) when a request is lingering, unfulfilled.

Similarly, if something "more important" needs that resource, the
task needs to know that it has been "reappropriated" and take
remedial actions ("Hmmm... I was able to dispense 6.2 gallons.
*If* I can reacquire the resource, soon, I can just dispense
another 8.14 gallons and I'm golden!  OTOH, if I have to wait
hours or days to reacquire it, I may have to start over again.
*Or*, signal a failure as the plants relying on that water
have probably died from dehydration!")

In other cases, the resource may be a computational one.  I.e.,
having access to CPU time/memory on another node.  If that resource
is revoked, the workload manager has to find some other node to
satisfy the request *and* figure out what portion of the operation
previously scheduled on that node must be recreated, etc.

[My point here is:  different tasks tend to need different recovery
strategies.]

> The problem being that there will always be a
> point in time between it testing that is still has the right to use it,
> and the actual access,

Exactly!  Hence the need for an asynchronous notification mechanism.
E.g. a "signal".  So, when the signal is sent, a thread processes
that notification *before* the task actually is allowed to execute
another instruction (that handler could kill the task, suspend it
until the handler can reacquire ownership of the resource, or
set a flag that the task can examine at some convenient point in
its process, etc.).

I.e., the remedy tends to be defined by the use (UNuse)?

> unless of course you need to fill your code with
> critical sections for EVERY use of the resource.

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