>From: Gordon Vreugdenhil <gordonv@model.com> >For fork-join_none within a function, one could >argue that it would be compliant to implement fork-join_none as though >it were a fork-join since the conceptual "independent threads" >(which can't block) can all be "scheduled" immediately after >the "join_none" and before the next sequential statement per >LRM scheduling rules. But one would be wrong :-). Table 11-1 states that the spawned processes do not start executing until the parent thread executes a blocking statement. This requirement conflicts with those 1364 LRM scheduling rules you mention, which allow suspending any process in favor of any other that is ready to run. This is presumably intended to override those rules in this case, placing restrictions on the scheduling order. This may defeat the intended purposes of those 1364 scheduling rules, and may not have been a good idea, but it's what the 1800 LRM specifies. This means that the "independent threads" cannot be "scheduled" immediately after the "join_none" and be compliant. The standard requires that they not be executed before the parent reaches a blocking statement, which cannot happen until after it returns. >At this point, I think that both the utility of fork-join_none >or even fork-join_any is questionable (I don't like fork-join >in functions for that reason as well) and since it is likely >to cause confusion in the user base, I'd really prefer to just >make it illegal. > >Does anyone have a compelling use model for allowing this? No, I don't see a good use for this. The only argument I can see is backward-compatibility, which applies to fork-join, but not fork-join_none or fork-join_any. Steven Sharp sharp@cadence.comReceived on Fri Feb 17 11:05:19 2006
This archive was generated by hypermail 2.1.8 : Fri Feb 17 2006 - 11:06:17 PST