Re: Multitasking in C++...
werasm wrote:
Hi all,
Hi.
[snipped]
- Have some of you implemented similar schemes/architectures?
Yes, though in my model, the client does not necessarily reside on same
server.
- Could a scheme like this be considered as a viable candidate for
intertask/thread communication in C++. Of course, the notion of
task/thread currently does not even exist in C++.
IMO, communicating between two threads in the same process by stuffing
a mutex-protected-plus-semaphore queue is so straigthforward, any
standardization of it is more likely to result in an impediment than a
benefit. The fundamental question always centers around primitives:
1. How good are your primitives?
2. With what facility can you synthesize the system you need from
those primitives?
Let's see, I already have in my arsenal, as probably do others:
1. Queue<>
2. Shared<> (mutex wrapper)
3. Counted<> (semaphore wrapper)
4. Thread::Object (many don't have this)
I can use (4) to create as many threads as I want. The data structure
containing struct Command { }'s would be
Shared<Counted<Queue<Command> > > commands;;
commands.acquire();
commands.push(Command());
commands.release();
- The idea is then (to summarize), to create a high level callable
entity in C++ that is associated with a context (or not).
- To have the notion of Context, where context represents what is
currently known as "Thread of execution", each Context just consisting
of code to execute callable entities when they arrive.
Are these real threads or not?
Obviously, sometimes traditional Mutual Exclusion is still required,
but we have found this to be minimal when not using the message queues,
and failsafe (and abstracted) when using the message queues.
Also, you mentioned tha blocking does not happen on insertion of
commands into your queue.
I'd be wary of this. :)
Best,
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]