* Multiple entry tasks @ 2001-04-18 14:57 Lutz Donnerhacke 2001-04-18 16:22 ` Marin David Condic 0 siblings, 1 reply; 19+ messages in thread From: Lutz Donnerhacke @ 2001-04-18 14:57 UTC (permalink / raw) Simple problem, but no clue: I have a task with multiple entry points. I'd like to serve some entries before the rest and like to have a terminate alternative. How should I solve this? (Currently I added a protected type and used it, but this violates the encapsulation) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-18 14:57 Multiple entry tasks Lutz Donnerhacke @ 2001-04-18 16:22 ` Marin David Condic 2001-04-18 18:12 ` Ted Dennison 2001-04-19 8:17 ` Jean-Pierre Rosen 0 siblings, 2 replies; 19+ messages in thread From: Marin David Condic @ 2001-04-18 16:22 UTC (permalink / raw) Sounds like you want some version of guarded entries in a select statement. I have not attempted to do this before (kids: don't try this at home - we *are* trained professionals!), nor have I run this past a compiler (spank me for this later if it doesn't work) but I *think* you want some version of the following: select when (Entry2'Count <= 0) and (Entry1'Count <= 0) => accept Entry3 ; when (Entry1'Count <= 0) => accept Entry2 ; or accept Entry1; else terminate; end select ; Let me know if a) some variation of this compiles and b) it does what you intended... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message news:slrn9dralj.k4.lutz@taranis.iks-jena.de... > Simple problem, but no clue: > > I have a task with multiple entry points. I'd like to serve some entries > before the rest and like to have a terminate alternative. How should I solve > this? (Currently I added a protected type and used it, but this violates the > encapsulation) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-18 16:22 ` Marin David Condic @ 2001-04-18 18:12 ` Ted Dennison 2001-04-18 18:57 ` Ted Dennison 2001-04-18 19:46 ` Marin David Condic 2001-04-19 8:17 ` Jean-Pierre Rosen 1 sibling, 2 replies; 19+ messages in thread From: Ted Dennison @ 2001-04-18 18:12 UTC (permalink / raw) In article <9bkevj$61k$1@nh.pace.co.uk>, Marin David Condic says... > >*are* trained professionals!), nor have I run this past a compiler (spank me >for this later if it doesn't work) but I *think* you want some version of >the following: > >select > when (Entry2'Count <= 0) and (Entry1'Count <= 0) => > accept Entry3 ; or > when (Entry1'Count <= 0) => > accept Entry2 ; >or > accept Entry1; >else > terminate; >end select ; I don't think the guards get recalcuated when new entries come in, only when the top of the select statement is reached. Thus if nothing is available then, it will continue to wait indefinitely for Entry1, even if an Entry2 or Entry3 comes in later. One way to get some entries to have priority over others would be to use "pragma Queuing_Policy (Priority_Queuing);" With that set, the entries will be accepted in the order of the priority of their tasks. The drawbacks to this are that your scheme depends on task priorities, which might not mesh well with what you are trying to do, and that this pragma requires that your compiler supports the Real-Time annex (D). If you do it this way, you are really prioritizing the *clients* (rendezvous initiating tasks), not the entires. An different way, that prioritizes the entries themselves, is to use cascading select-else structures: select accept Entry1; else select accept Entry2; else select accept Entry1; or accept Entry2; or accept Entry3; or terminate; end select; end select; end select; A third possiblity, that works with a single entry, is to keep track of the highest priority entry (this part is tricky), and use the "requeue" statement creatively. How exactly to accomplish this depends a lot on your scheme for setting and keeping track of priorities, and can get quite interesting, so I won't burden everyone here with an example (as much as I'd love to. Requeue is really fun to play with). --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-18 18:12 ` Ted Dennison @ 2001-04-18 18:57 ` Ted Dennison 2001-04-18 20:16 ` Marin David Condic 2001-04-18 19:46 ` Marin David Condic 1 sibling, 1 reply; 19+ messages in thread From: Ted Dennison @ 2001-04-18 18:57 UTC (permalink / raw) In article <vOkD6.1839$D4.178910@www.newsranger.com>, Ted Dennison says... > >In article <9bkevj$61k$1@nh.pace.co.uk>, Marin David Condic says... >> >>select >> when (Entry2'Count <= 0) and (Entry1'Count <= 0) => >> accept Entry3 ; > >or > >> when (Entry1'Count <= 0) => >> accept Entry2 ; >>or >> accept Entry1; >>else >> terminate; >>end select ; > > >I don't think the guards get recalcuated when new entries come in, only when the >top of the select statement is reached. Thus if nothing is available then, it >will continue to wait indefinitely for Entry1, even if an Entry2 or Entry3 comes >in later. Doh! I misread the conditionals. If waiting occurs, all the guards will be *open*. That should work fine (assuming the "or" is added, of course). If multiple rendezvous become active before this task gets around to accepting one, I suppose the priority principle could be violated. But that's a pretty marginal case. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-18 18:57 ` Ted Dennison @ 2001-04-18 20:16 ` Marin David Condic 2001-04-19 14:02 ` Ted Dennison 0 siblings, 1 reply; 19+ messages in thread From: Marin David Condic @ 2001-04-18 20:16 UTC (permalink / raw) If multiple rendezvous become active before you hit the select, I'd imagine that they would have to be queued according to the priority of the tasks that called the entries. It is a marginal case but probably worth thinking about for a minute anyway... If two tasks of the same priority were calling, say, Entry2 - then its a coin toss as to which gets there first. If two tasks of the same priority were calling different entries, then the priority of the entry would decide which got to run. If two tasks of different priority call the same entry, then the higher priority task gets it. If two tasks of different priorities call different entries, then you might get a priority inversion - if both Entry2 and Entry3 have callers, then Entry3 is blocked when you get to evaluating it.So even if the task calling Entry3 is of higher priority, it gets blocked until Entry2 finishes. So there's only one case that is ill-defined - except that in a single processor environment, one of them would have to have arrived there first. In a multiple-processor environment, one starts to imagine true simultaneous arrival - which I guess is going to get somehow arbitrated by the hardware. (Unless the Indivisible Instruction finally meets the Unmaskable Interrupt! :-) You'll probably at least have a deterministic answer - if not the answer you wanted. Some other mechanism needs to decide the same-priority-same-entry case. The priority inversion is a consequence of entry priority having preference over task priority. Presumably, you're design needed to consider that when you dreamed up the notion of prioritizing the entries. (I think that case is in the ARM under the "I Weep For You!" rule of task design. ;-) Truly an interesting state of affairs, eh? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" <dennison@telepath.com> wrote in message news:8slD6.1888$D4.184457@www.newsranger.com... > In article <vOkD6.1839$D4.178910@www.newsranger.com>, Ted Dennison says... > Doh! I misread the conditionals. If waiting occurs, all the guards will be > *open*. That should work fine (assuming the "or" is added, of course). If > multiple rendezvous become active before this task gets around to accepting one, > I suppose the priority principle could be violated. But that's a pretty marginal > case. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-18 20:16 ` Marin David Condic @ 2001-04-19 14:02 ` Ted Dennison 2001-04-19 14:28 ` Marin David Condic 0 siblings, 1 reply; 19+ messages in thread From: Ted Dennison @ 2001-04-19 14:02 UTC (permalink / raw) In article <9bksmp$ang$1@nh.pace.co.uk>, Marin David Condic says... > >If multiple rendezvous become active before you hit the select, I'd imagine >that they would have to be queued according to the priority of the tasks >that called the entries. It is a marginal case but probably worth thinking >about for a minute anyway... Hmmm. That's an interesting issue, and I suspect you are right, although the language may require the select statement to make an arbitrary choice in this circumstance. I'm not sure. However, I was referring to the "priority" we are trying to encode into the 3 entries, not task priority. If we make a development policy that they are to be the same (relatively), then I guess it would work out as you say. But in that case, you might as well use the Priority_Queuing entry queuing policy, and not even have to worry about guards at all. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-19 14:02 ` Ted Dennison @ 2001-04-19 14:28 ` Marin David Condic 0 siblings, 0 replies; 19+ messages in thread From: Marin David Condic @ 2001-04-19 14:28 UTC (permalink / raw) I've never played with Priority_Queuing - not an area I know enough to talk about. However the name suggests that it might provide the answer for the original problem. It depends on what you want to do, right? Otherwise, the cascading selects suggested by you and JPR are probably a cleaner approach than looking at guard conditions. (It corresponds nicely to the sort of cascading if's that typically get created to handle non-tasking "priority" issues & is probably more clear to the reader as to what is being done.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" <dennison@telepath.com> wrote in message news:udCD6.2834$D4.281263@www.newsranger.com... > In article <9bksmp$ang$1@nh.pace.co.uk>, Marin David Condic says... > However, I was referring to the "priority" we are trying to encode into the 3 > entries, not task priority. If we make a development policy that they are to be > the same (relatively), then I guess it would work out as you say. But in that > case, you might as well use the Priority_Queuing entry queuing policy, and not > even have to worry about guards at all. > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-18 18:12 ` Ted Dennison 2001-04-18 18:57 ` Ted Dennison @ 2001-04-18 19:46 ` Marin David Condic 2001-04-19 21:52 ` Robert A Duff 1 sibling, 1 reply; 19+ messages in thread From: Marin David Condic @ 2001-04-18 19:46 UTC (permalink / raw) Thanks for catching my typo with the missing "or" part. I don't think this is a simple problem to solve. Almost anything one does to fiddle with the availability of entries is going to make the complexity go way up real fast. As you observe, it is a way of trying to prioritize the entries. Ada would prefer it if you prioritized the tasks. Cascading the selects is an interesting mechanism. I'm not sure there is any answer that will be definitive. (Short of a language mod allowing one to prioritize entries?) Maybe the real answer is to divide the entries up into individual tasks and assign priorities? (This is, of course, a structural change that gets away from the original question.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-18 19:46 ` Marin David Condic @ 2001-04-19 21:52 ` Robert A Duff 2001-04-24 9:19 ` Lutz Donnerhacke 0 siblings, 1 reply; 19+ messages in thread From: Robert A Duff @ 2001-04-19 21:52 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes: > Cascading the selects is an interesting mechanism. I'm not sure there is any > answer that will be definitive. (Short of a language mod allowing one to > prioritize entries?) Under the Priority_Queueing policy, the entries are prioritized -- you write the higher-priority accepts before the lower-priority ones. Task priorities take precedence over entry priorities, however. I'm not sure whether that's what the original poster wanted, but if all the tasks are the same priority, then the order of the accept statements determines the priority of the entries. See RM-D.4(14). - Bob ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-19 21:52 ` Robert A Duff @ 2001-04-24 9:19 ` Lutz Donnerhacke 0 siblings, 0 replies; 19+ messages in thread From: Lutz Donnerhacke @ 2001-04-24 9:19 UTC (permalink / raw) * Robert A Duff wrote: >Under the Priority_Queueing policy, the entries are prioritized -- you >write the higher-priority accepts before the lower-priority ones. Task >priorities take precedence over entry priorities, however. I'm not >sure whether that's what the original poster wanted, but if all the >tasks are the same priority, then the order of the accept statements >determines the priority of the entries. Thank you. That's the last one of a lot of very useful hints. I came to the conclusion, that in every situation where a posting to cla is necessary the code design is wrong anyway. So postings to cla are a sure sign of bad programming ;-) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-18 16:22 ` Marin David Condic 2001-04-18 18:12 ` Ted Dennison @ 2001-04-19 8:17 ` Jean-Pierre Rosen 2001-04-19 14:42 ` Ted Dennison 1 sibling, 1 reply; 19+ messages in thread From: Jean-Pierre Rosen @ 2001-04-19 8:17 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1730 bytes --] "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit dans le message news: 9bkevj$61k$1@nh.pace.co.uk... > Sounds like you want some version of guarded entries in a select statement. > I have not attempted to do this before (kids: don't try this at home - we > *are* trained professionals!), nor have I run this past a compiler (spank me > for this later if it doesn't work) but I *think* you want some version of > the following: > > select > when (Entry2'Count <= 0) and (Entry1'Count <= 0) => > accept Entry3 ; > when (Entry1'Count <= 0) => > accept Entry2 ; > or > accept Entry1; > else > terminate; > end select ; > This is wrong. Guards are evaluated only when the select is entered (unlike POs), therefore if a task cancels its call (through timed entry call) while the guards are being evaluated, you may end up in a situation of infinite blocking. The 'Count attribute should be used only with great care outside a PO. The proper way of checking if a queue is empty is to use the else part of the select statement. Therefore: select accept Entry1; else select accept Entry2; else select accept Entry1; or accept Entry2; or accept Entry3; or terminate; end select; end select; end select; Now, an exercise to see who is following. Those who attended an Adalog training session are excluded from the competition :-) 1) Show that the sequence above exhibits a race condition 2) Show that the race condition is perfectly acceptable. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-19 8:17 ` Jean-Pierre Rosen @ 2001-04-19 14:42 ` Ted Dennison 2001-04-19 15:01 ` Marin David Condic 2001-04-19 15:02 ` Jean-Pierre Rosen 0 siblings, 2 replies; 19+ messages in thread From: Ted Dennison @ 2001-04-19 14:42 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2843 bytes --] In article <9bm76r$mf6$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > > >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit dans >le message news: 9bkevj$61k$1@nh.pace.co.uk... >> select >> when (Entry2'Count <= 0) and (Entry1'Count <= 0) => >> accept Entry3 ; >> when (Entry1'Count <= 0) => >> accept Entry2 ; >> or >> accept Entry1; >> else >> terminate; >> end select ; >> >This is wrong. Guards are evaluated only when the select is entered (unlike >POs), therefore if a task cancels its call (through timed entry call) while >the guards are being evaluated, you may end up in a situation of infinite >blocking. :-) I made the same misreading as you on my first post. The guards will only close if there is already an entry available on another branch. In that case the higher priority entry will be immediately accepted, so there will be no blocking at all. Thus there cannot be infinte blocking (execpt where intended :-) ). I think the confusing part was that he used "<= 0" rather than "= 0". 'count logically shouldn't ever go negative, but I guess he was trying to be safe (perhaps there's some degenerate case about that in the LRM. I'd check it if this were production code I was writing). I'd only expected to see a two-character boolean of ">= 0", so that's what my brain reported. :-( >select > accept Entry1; >else > select > accept Entry2; > else > select > accept Entry1; > or > accept Entry2; > or > accept Entry3; > or > terminate; > end select; > end select; >end select; > >1) Show that the sequence above exhibits a race condition >2) Show that the race condition is perfectly acceptable. Marin's code has the same "race condition". I also touched on that in a previous post, but I'm always happy to go into more detail. :-) Its quite possible for this server task to find no entries available and block down in the inner select (or in Marin's case, block with all the guards open). At that point, its quite possible for two separate tasks to become ready and enqueue on Entry1 and Entry2 before this server task becomes active again. At that point, the selection of which entry to accept will be based on factors other than the priority we have tried to set up. However, I would consider such "simultanious entries" to be a degenerate case which is really no worse than the case where the server task accepts Entry_3 8 CPU cycles before a client requests Entry_1. The duration of the inversion is practicly the same, and in both cases Entry_1 is still properly queued, and will take priority over any other Entry_2s and Entry_3s that arrive afterwards. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-19 14:42 ` Ted Dennison @ 2001-04-19 15:01 ` Marin David Condic 2001-04-19 15:02 ` Jean-Pierre Rosen 1 sibling, 0 replies; 19+ messages in thread From: Marin David Condic @ 2001-04-19 15:01 UTC (permalink / raw) Sorry. Force of habit. I generally code comparisons that avoid things like "X = 0" out of fear that one day, somehow, X may be -1 and that still means I want to take action based on nothing being there. (The 'Count attribute returns Universal Integer - so negative numbers are at least within the set - if not something that would actually get returned.) I've learned especially to avoid that comparison on floating point numbers and there is just a sort of paranoia in the back of my mind that wants to account for all possible - and impossible - conditions. (Forgive us our paranoia, for we know what we do!) So if Entry1'Count is > 0, I definitely know I've got entries called - the negation of that condition is "<=" and that accounts for everything. I suppose I could have said "not (Entry1'Count > 0)" but that may have been even more confusing! MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" <dennison@telepath.com> wrote in message news:pPCD6.2928$D4.287059@www.newsranger.com... > In article <9bm76r$mf6$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > I think the confusing part was that he used "<= 0" rather than "= 0". 'count > logically shouldn't ever go negative, but I guess he was trying to be safe > (perhaps there's some degenerate case about that in the LRM. I'd check it if > this were production code I was writing). I'd only expected to see a > two-character boolean of ">= 0", so that's what my brain reported. :-( > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-19 14:42 ` Ted Dennison 2001-04-19 15:01 ` Marin David Condic @ 2001-04-19 15:02 ` Jean-Pierre Rosen 2001-04-19 19:12 ` Ted Dennison 1 sibling, 1 reply; 19+ messages in thread From: Jean-Pierre Rosen @ 2001-04-19 15:02 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2182 bytes --] "Ted Dennison" <dennison@telepath.com> a �crit dans le message news: pPCD6.2928$D4.287059@www.newsranger.com... > In article <9bm76r$mf6$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > > > > > >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit dans > >le message news: 9bkevj$61k$1@nh.pace.co.uk... > >> select > >> when (Entry2'Count <= 0) and (Entry1'Count <= 0) => > >> accept Entry3 ; > >> when (Entry1'Count <= 0) => > >> accept Entry2 ; > >> or > >> accept Entry1; > >> else > >> terminate; > >> end select ; > >> > >This is wrong. Guards are evaluated only when the select is entered (unlike > >POs), therefore if a task cancels its call (through timed entry call) while > >the guards are being evaluated, you may end up in a situation of infinite > >blocking. > > :-) > > I made the same misreading as you on my first post. The guards will only close > if there is already an entry available on another branch. In that case the > higher priority entry will be immediately accepted, so there will be no blocking > at all. Thus there cannot be infinte blocking (execpt where intended :-) ). I did the same misreading as you, but realized it before I posted. Now, you misread my response ;-) The sequence of events I was thinking of is the following: Imagine that at the time you reach the select, there are calls for Entry2 and Entry3. 1) Evaluate the guard for Entry3. Since there is a call to Entry2, the guard is closed 2) The call to Entry2 times out (it was a timed entry call). 3) Finish evaluating guards and block on select. You start waiting for Entry2 and Entry1, although there is a call to Entry3 pending If the logic of the caller is such that the next call to Entry1 or Entry2 will be issued only after Entry3 is serviced, you have dead-lock. > I think the confusing part was that he used "<= 0" rather than "= 0". Agreed. I was confused by that too. And no, a 'Count cannot be negative. I always find this kind of "extra security" damaging. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-19 15:02 ` Jean-Pierre Rosen @ 2001-04-19 19:12 ` Ted Dennison 2001-04-20 14:17 ` Jean-Pierre Rosen 0 siblings, 1 reply; 19+ messages in thread From: Ted Dennison @ 2001-04-19 19:12 UTC (permalink / raw) In article <9bmuo9$50h$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > >The sequence of events I was thinking of is the following: >2) The call to Entry2 times out (it was a timed entry call). Ahhh. I didn't think about timed entry calls. Hmmm. So you are saying that the runtime can change the state of the entry queues between the start of a select statement and its decision to block or immediately accept an entry? In that case, an "abort"ed task would hose him as well, right? Generally I find that one has to be very carful about using timed or tenative entry calls. As a general rule, you have to be damn sure that the server will at some point sit and wait for your entry. If there's an "else" or "delay" clause on the server's selective wait, you can get into a nasty case of livelock. Since I generally need to use one of those clauses, I don't use timed or tenative rendezvous very much. Since I usually can't use them anyway, I don't think its much of a hardship to prohibit timed rendezvous (and aborts) for clients of this server. What you gain by doing this is an easier to maintain structure. With the way we did it, there are two select branches that must be maintined in lock-step for all but the highest-priority entry. That's not a big deal with our little toy example, as there was no code in any of the branches. But for a complicated server with loads of code in each branch, it could be a very big deal indeed. Then again, its possible you might want to do different things if the entry was accepted immediately vs. waited for. In that case what we did would be better. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-19 19:12 ` Ted Dennison @ 2001-04-20 14:17 ` Jean-Pierre Rosen 2001-04-20 19:04 ` Ted Dennison 0 siblings, 1 reply; 19+ messages in thread From: Jean-Pierre Rosen @ 2001-04-20 14:17 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1729 bytes --] "Ted Dennison" <dennison@telepath.com> a �crit dans le message news: sMGD6.3326$D4.330928@www.newsranger.com... > Ahhh. I didn't think about timed entry calls. Hmmm. So you are saying that the > runtime can change the state of the entry queues between the start of a select > statement and its decision to block or immediately accept an entry? In that > case, an "abort"ed task would hose him as well, right? The point in general is that the 'Count attribute returns the length of the queue at the time it is called, but that it can increase or decrease (due to timed entry calls or -you're right- abort) at any time. You can use it for optimization purpose; for example, you might want to serve the longest queue first. If there is a race condition, you may very rarely choose a queue that is suboptimal by 1 - that's acceptable. But 'Count should not be used in an all-or-nothing context. > Generally I find that one has to be very carful about using timed or tenative > entry calls. As a general rule, you have to be damn sure that the server will at > some point sit and wait for your entry. If there's an "else" or "delay" clause > on the server's selective wait, you can get into a nasty case of livelock. Since > I generally need to use one of those clauses, I don't use timed or tenative > rendezvous very much. Timed entry calls are very useful: a client may well want to do something else if the server does not accept a request within a given time frame. You might well argue that in some contexts, all calls must be timed (i.e. ensure not infinite blocking). -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-20 14:17 ` Jean-Pierre Rosen @ 2001-04-20 19:04 ` Ted Dennison 2001-04-23 6:55 ` Jean-Pierre Rosen 0 siblings, 1 reply; 19+ messages in thread From: Ted Dennison @ 2001-04-20 19:04 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2519 bytes --] In article <9bpgnu$blc$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > >"Ted Dennison" <dennison@telepath.com> a �crit dans le message news: >sMGD6.3326$D4.330928@www.newsranger.com... >> some point sit and wait for your entry. If there's an "else" or "delay" >> clause on the server's selective wait, you can get into a nasty case of >> livelock. >Timed entry calls are very useful: a client may well want to do something I'd agree that they can occasionally be useful. However, they are tricky and fragile. >else if the server does not accept a request within a given time frame. You >might well argue that in some contexts, all calls must be timed (i.e. ensure >not infinite blocking). I'd argue that ensuring finite blocking for clients is the *server's* responsibility. If the client is making an entry call, then presumably it *needs* the server to do something. So if the client is going to time out of the call, it will probably need to come back and make the same entry call later. If the sever *still* won't service the call, the client is really infintiely blocking, just with a loop instead of a single block. To prevent dead/livelocks, its really best to think of tasks in terms of clients and servers. Tasks making entry calls are clients, and accepting tasks are servers. In this context tenative/timed entry calls are one way to allow a server task to *also* be a client, without neglecting its own client(s). However, for this to work, the server task called by your hybrid client-server task's *must* at some point block (with no time-out) on the hybrid's entry. If the server task has a timeout in its accept, there's a possiblity that the timeouts of the two tasks will sync up, with the result being that they will never (or very rarely) both be ready for the rendezvous. You might be able to arrange this properly at first, but its quite common to discover the need to add a timeout to a server's accept statment later in debugging or maintainence, and there's no simple way to even see that there's a client somewhere in the system that will be hosed by this. To top it off, the fix to the client is likely going to have to be a redesign. Yeeeeach. Typically if you find the need for a client-server task, it is much better to just use another task or protected object to internally queue up requests to act as a sort of client/server "gender-bender". --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-20 19:04 ` Ted Dennison @ 2001-04-23 6:55 ` Jean-Pierre Rosen 2001-04-23 13:50 ` Ted Dennison 0 siblings, 1 reply; 19+ messages in thread From: Jean-Pierre Rosen @ 2001-04-23 6:55 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2775 bytes --] "Ted Dennison" <dennison@telepath.com> a �crit dans le message news: jL%D6.4582> I'd argue that ensuring finite blocking for clients is the *server's* > responsibility. If the client is making an entry call, then presumably it > *needs* the server to do something. So if the client is going to time out of the > call, it will probably need to come back and make the same entry call later. If > the sever *still* won't service the call, the client is really infintiely > blocking, just with a loop instead of a single block. Interesting. I'd rather argue that in a client-server relationship, none of the partners should trust the other one; each ensures its own security. It is true that if the client times out, it will often come back later. Mut in the meantime, it could ask on the console "Server not responding, try again?", or try a different server, or just report a failure to upper levels ("connection lost"), or.... > To prevent dead/livelocks, its really best to think of tasks in terms of clients > and servers. Tasks making entry calls are clients, and accepting tasks are > servers. Agreed >In this context tenative/timed entry calls are one way to allow a > server task to *also* be a client, without neglecting its own client(s). > However, for this to work, the server task called by your hybrid client-server > task's *must* at some point block (with no time-out) on the hybrid's entry. If > the server task has a timeout in its accept, there's a possiblity that the > timeouts of the two tasks will sync up, with the result being that they will > never (or very rarely) both be ready for the rendezvous. You might be able to > arrange this properly at first, but its quite common to discover the need to add > a timeout to a server's accept statment later in debugging or maintainence, and > there's no simple way to even see that there's a client somewhere in the system > that will be hosed by this. To top it off, the fix to the client is likely going > to have to be a redesign. Yeeeeach. That's one use of timed entry calls. I've met other ones... > Typically if you find the need for a client-server task, it is much better to > just use another task or protected object to internally queue up requests to act > as a sort of client/server "gender-bender". There once was a famous, though unpublished paper by P. Kruchten about the "Sex of tasks", that neatly discussed "male" tasks (callers only), "female" tasks (accepters only), "hermaphrodites tasks", one special case of it being the "gender bender", etc. I don't think I have it anymore, nor that Philippe is still listening c.l.a... -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Multiple entry tasks 2001-04-23 6:55 ` Jean-Pierre Rosen @ 2001-04-23 13:50 ` Ted Dennison 0 siblings, 0 replies; 19+ messages in thread From: Ted Dennison @ 2001-04-23 13:50 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1965 bytes --] In article <9c0jot$cah$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > > >"Ted Dennison" <dennison@telepath.com> a �crit dans le message news: >jL%D6.4582> I'd argue that ensuring finite blocking for clients is the >> *server's* responsibility. If the client is making an entry call, then .. >Interesting. I'd rather argue that in a client-server relationship, none of >the partners should trust the other one; each ensures its own security. It If we were talking TCP/IP (or perhaps annex E), I'd probably agree with you. But within the confines of a single program, I have to be able to count on my servers working properly, just like I have to be able to count on my normal subprograms working properly. >>In this context tenative/timed entry calls are one way to allow a >> server task to *also* be a client, without neglecting its own client(s). >That's one use of timed entry calls. I've met other ones... If we expand the concept of a "server" to include serving things other than Ada tasks (eg: a display, a request queue, a device), I think this would cover just about every use I can think of for timed entry calls. >There once was a famous, though unpublished paper by P. Kruchten about the >"Sex of tasks", that neatly discussed "male" tasks (callers only), "female" >tasks (accepters only), "hermaphrodites tasks", one special case of it being >the "gender bender", etc. I don't think I have it anymore, nor that Philippe >is still listening c.l.a... That's a shame. I'd be interested in what he had to say on the subject of "hermaphrodite tasks". I think there's a few sets of situations where they can be safe to use, if only one knows how to recognise the situation (and takes pains to keep the conditions the same, even through later redesigns). But nearly every time I've created one, I've regretted it. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2001-04-24 9:19 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-18 14:57 Multiple entry tasks Lutz Donnerhacke 2001-04-18 16:22 ` Marin David Condic 2001-04-18 18:12 ` Ted Dennison 2001-04-18 18:57 ` Ted Dennison 2001-04-18 20:16 ` Marin David Condic 2001-04-19 14:02 ` Ted Dennison 2001-04-19 14:28 ` Marin David Condic 2001-04-18 19:46 ` Marin David Condic 2001-04-19 21:52 ` Robert A Duff 2001-04-24 9:19 ` Lutz Donnerhacke 2001-04-19 8:17 ` Jean-Pierre Rosen 2001-04-19 14:42 ` Ted Dennison 2001-04-19 15:01 ` Marin David Condic 2001-04-19 15:02 ` Jean-Pierre Rosen 2001-04-19 19:12 ` Ted Dennison 2001-04-20 14:17 ` Jean-Pierre Rosen 2001-04-20 19:04 ` Ted Dennison 2001-04-23 6:55 ` Jean-Pierre Rosen 2001-04-23 13:50 ` Ted Dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox