Topic: Where next for Standard C++? what about task and parallelism


Author: "Alain Coetmeur" <acoetmeur@icdc.caissedesdepots.fr>
Date: 1997/11/27
Raw View
--MimeMultipartBoundary
Content-Type: text/plain;
 charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

One point where C++ could evolve
could be to support a multi-thread model
like ADA or Java, or some other language...
Like the STL it have to be:
- as efficient as possible for a given
  functionality
- open to any implementation
  (any OS)
why not
- really support coprocedure in C++ (not setjmp)
- propose a template for a scheduler
   in a way similar to STL container, so
   that you have standard scheduler, but can build your own...
- add locking primitives or critical section
   like in java (lock on method, lock on block, lock on object...)
   , but fully open to any implementation of
   lock or of scheduler, either home made, OS made...
- make all fully plugable on a
   NT-thread/NTkernel/Posix-thread/Real-Time Monitor...
  without user change... in a way similar to Allocator in STL
the STL seems to be a model for such implementation,
with a strong theorical definition, total openness
and extensibility, and a good reference implementation...
with this, there should be a fully reentrant
STL implementation...

why not a Standard Multi Thread Library (SMTL) .
smile 8)

--
Alain Coetmeur. Informatique-CDC , mailto:acoetmeur@icdc.caissedesdepots.fr
<<Mes propos n'engagent que moi. #8*). my words are only mine. >>


--MimeMultipartBoundary--
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]