Re: [boost] Re: Boost.Threads - Questions

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-20 20:37:18

William Kempf wrote:
 
> The only other solution is to allow threads to be created in a "suspended"
> state and to "resume" them only when you've set the state,

        Why is that the 'only other soution'?
What about:

        smart_ptr<thread> p = create_thread<smart_ptr>(THREAD_FUNC);

where:

        thread_func::operator()(smart_ptr<thread>)

is passed the same 'p' value that create_thread returns?

> Then you need synchronization via a "monitor", whether this is built in or
> done manually.

        Yes. But that's easy for you to do: the interlock needs
to be optional for performance reasons, and the interface
needs quite some thought to be general enough to bother.
But it looks like a genuine need: it seems to follow from
C++ serial construction that some things you can do in C
can't be done so easily in C++: prototypically:

        p = new X(q);
        q = new Y(p);

In C, this is easy:

        p = malloc();
        q = malloc();
        p->link = q;
        q->link = p;

because there are no constructors, and no language enforced
construction invariants.

A solution uses template templates:

        p = new X<Y>();
        q = p->get_q();

with

        X() : q(new Y(this)) {}

or, by passing some other kind of 'factory' for Y's.

I.e.: this problem is more general than threads.
But a thread solution is harder for the client to implement.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net