jat@xavax.com (John Tamplin) (05/05/90)
In article <263BF5E3.16516@paris.ics.uci.edu> rfg@paris.ics.uci.edu (Ronald Guilmette) writes: ... >Note that in the class `foo' shown above, the member function member_2 is >preceded by a new keyword, i.e. "exempt". In the scheme proposed here, a >call to a member function declared as "exempt" would cause the normal >(implicit) pre and/or post member function invocations to be suppressed >for that member function only. > >The syntactic & semantic rules for the "exempt" keyword, would be virtually >the same as for the "virtual" keyword, except that it should be allowable for >constructors to be declared as "exempt". (Note that destructors can be >virtual, and they should also be allowed to be "exempt".) The problem with this is that there is no way to implement something like the normal readers/writers solution: n readers with no writers or 1 writer with no readers. To do that you need to know which member function is being called, and for other solutions you might even need to know the arguments. It is simple to put a call to lock() and unlock() around the body of a member function in the simple case and for more complicated cases you need special code for each member function anyway. I have not seen the Capsule stuff myself, but from the short except given before I would agree that it adds too much fluff for not enough functionality. The par section appears to provide enough functionality for readers and writers, but I don't see a clean way to extend the syntax to more difficult problems. Another problem is you don't get to specify whether you want gated service, prioritized service, or what kind of fairness guarantees you want. I myself prefer to just use standard C++ and insert "mutex.P()" and "mutex.V()" around my member functions. When I want more sophisticated concurrency control, I write it myself. -- John Tamplin Xavax jat@xavax.COM 2804 S Memorial Parkway ...!uunet!xavax!jat Huntsville, AL 35801
rfg@ics.uci.edu (Ronald Guilmette) (05/05/90)
In article <1990May4.195250.9662@xavax.com> jat@xavax.com (John Tamplin) writes: >In article <263BF5E3.16516@paris.ics.uci.edu> rfg@paris.ics.uci.edu (Ronald Guilmette) writes: >... >>Note that in the class `foo' shown above, the member function member_2 is >>preceded by a new keyword, i.e. "exempt". In the scheme proposed here, a >>call to a member function declared as "exempt" would cause the normal >>(implicit) pre and/or post member function invocations to be suppressed >>for that member function only. >> >>The syntactic & semantic rules for the "exempt" keyword, would be virtually >>the same as for the "virtual" keyword, except that it should be allowable for >>constructors to be declared as "exempt". (Note that destructors can be >>virtual, and they should also be allowed to be "exempt".) > >The problem with this is that there is no way to implement something like >the normal readers/writers solution: n readers with no writers or 1 writer >with no readers. I agree. The simple before & after methods feature that I elaborated on (it was actually invented/suggested by others before me) was not meant to solve all sorts of random problems in the world of parallel/concurrent processing. It is only meant to provide a simple and straightforward mechanism for factoring out code that commonly has to be done either at the beginning or at the end of a mjority of the member functions of a given class (and possibly its descendants). >I have not seen the Capsule stuff myself, but from the short except given >before I would agree that it adds too much fluff for not enough functionality. This was my primary point. >I myself prefer to just use standard C++ and insert "mutex.P()" and >"mutex.V()" around my member functions. If before/after member functions *were* "standard" C++, you would not have to introduce all that redundancy (or do all that keyboarding). // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
ouij@xurilka.UUCP (exhausted jazz surfer) (05/05/90)
In article <1990May4.195250.9662@xavax.com> jat@xavax.com (John Tamplin) writes: >In article <263BF5E3.16516@paris.ics.uci.edu> rfg@paris.ics.uci.edu (Ronald Guilmette) writes: >... >>Note that in the class `foo' shown above, the member function member_2 is >>preceded by a new keyword, i.e. "exempt". In the scheme proposed here, a >>call to a member function declared as "exempt" would cause the normal >>(implicit) pre and/or post member function invocations to be suppressed >>for that member function only. >> [stuff deleted] > >The problem with this is that there is no way to implement something like >the normal readers/writers solution: n readers with no writers or 1 writer >with no readers. To do that you need to know which member function is >being called, and for other solutions you might even need to know the >arguments. It is simple to put a call to lock() and unlock() around the >body of a member function in the simple case and for more complicated cases >you need special code for each member function anyway. > >I have not seen the Capsule stuff myself, but from the short except given >before I would agree that it adds too much fluff for not enough functionality. >The par section appears to provide enough functionality for readers and >writers, but I don't see a clean way to extend the syntax to more difficult >problems. I ,repeat, the capsules stuff is not intended as an extension to C++. Nor should of it been brought up in this newsgroup. It is a new feature about to be added to Concurrent C++. We have no intention of modifying C++, that is left to its prophet and/or ansi committe. >Another problem is you don't get to specify whether you want >gated service, prioritized service, or what kind of fairness guarantees you >want. not true. Before people continue making rash judgments about Capsules considering that only a snippet was presented, get a copy of the paper ``Capsules: A shared memory mechanism'' [gehani 88] and lets move the discussion out this group. Now back to our regularly scheduled newgroup. >John Tamplin Xavax >jat@xavax.COM 2804 S Memorial Parkway >...!uunet!xavax!jat Huntsville, AL 35801 Ouij ---- Luigi Perrotta (sometimes) (514) 278 1837 Ubangi Research Inc info-ccc-request@xurilka.UUCP uunet!xurilka!ouij Concurrent C/C++ mailing list
rfg@ics.uci.edu (Ronald Guilmette) (05/06/90)
In article <131@xurilka.UUCP> ouij@xurilka.UUCP (exhausted jazz surfer) writes: > >I ,repeat, the capsules stuff is not intended as an extension >to C++. Nor should of it been brought up in this newsgroup. > >It is a new feature about to be added to Concurrent C++. >We have no intention of modifying C++, that is left to its prophet >and/or ansi committe. [...] > >Before people continue making rash judgments about Capsules >considering that only a snippet was presented, get a copy of >the paper ``Capsules: A shared memory mechanism'' [gehani 88] >and lets move the discussion out this group. To say that what happens in Concurrent C++ has no influence on (or should have no influence) on C++ (and in particular ANSI C++) is, IMHO, not correct. This is almost the same as saying that C++ had no influence on ANSI C (and we all know that it *did* have an influence). Obviously, whenever you talk about a superset of a given language (and especially a language for which a standard has not yet been codified) you are talking about things which represent possible good and useful additions to the base language itself. I see no reason why a discussion of Concurrent C++ features should be kept out of comp.lang.c++. Indeed, I'd say that discussing such things here may have a beneficial effect upon the final form of the ANSI C++ standard. (Well... I'm hopeful of that anyway.) // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.