Threading classes concept ?

[Lothar Behrens]

Hi,

I am thinking about using classes to encapsulate threads for my
application.

My requirements are the following:

The thread implementation sould not know what has to be implemented in
the
thread frunction nor it has to define an abstract method to force
implementation
in that. (Then the implementation could not be instantiated)

Also the implementation should not derive from the thread class or
their interface.
(No direct dependencies by linking against the threading library)

That given, I would be able to late bind the real thread
implementation by runtime loading
the instance from any DLL / so module.

Typical samples of a thread class using a static member fuction. But I
prefer to
use a member callback for that. This way I could separate a specific
thread
implementation from the thread base class and also use dynamic loading
of this
class.

In the sample here I have leaved the static member function to be
called at first level.

The trick here I also use on other member callback issues in my
application is a typedef
and store both, the instance to the implementation and the pointer to
the given member
function.

Is there any issue, that let invalidate my concept ?

Thanks for your time !

Lothar

class lb_I_ThreadImplementation;

typedef (lb_I_ThreadImplementation::*lbThreadFunction)();

// My base for all classes (like Mocrosoft COM)
class lb_I_Unknown;

class lb_I_Thread : public lb_I_Unknown {
public:
// The thread implementation instance
lb_I_ThreadImplementation* getThreadImpl() = 0;

// The callback
lbThreadFunction getThreadMemberCallback() = 0;

lbErrCodes setThreadCallback(lb_I_ThreadImplementation* impl,
lbThreadFunction Tfn) = 0;

virtual lbErrCodes create() = 0;

virtual lbErrCodes run() = 0;
virtual lbErrCodes stop() = 0;

virtual lbErrCodes pause() = 0;
virtual lbErrCodes resume() = 0;
};


class lbThreadInternal; // For various operating systems

class lbThread : public lb_I_Thread {
public:
lbThread();
virtual ~lbThread();

lb_I_ThreadImplementation* getThreadImpl();
lbThreadFunction getThreadMemberCallback();
lbErrCodes setThreadCallback(lb_I_ThreadImplementation* impl,
lbThreadFunction Tfn);

lbErrCodes create();

lbErrCodes run();
lbErrCodes stop();

lbErrCodes pause();
lbErrCodes resume();

private:
lbThreadInternal* thread_internal;

lb_I_ThreadImplementation* threadimpl;
lbThreadFunction _tFn;
};

// Platform based implementation
class lbThreadInternal {
public:
lbThreadInternal()
{
lb_hThread = 0;
}

// create a new (suspended) thread (for the given thread object)
lbErrCodes Create(lbThread *thread);

lbErrCodes run();
lbErrCodes stop();

lbErrCodes pause();
lbErrCodes resume();

// thread function
static DWORD WinThreadStart(lbThread *thread);

private:
HANDLE lb_hThread; // handle of the thread
DWORD lb_ThreadId; // thread id
};

DWORD lbThreadInternal::WinThreadStart(lbThread *thread)
{
// store the thread object in the TLS
if ( !::TlsSetValue(s_tlsThisThread, thread) )
{
// Write some useful logmessage
return (DWORD)-1;
}

if (thread == NULL) {
// Write some useful logmessage
return (DWORD)-1;
}

DWORD ret = (thread->getThreadImpl()->*((lbThreadFunction) (thread-

getThreadMemberCallback()))) ();

delete thread;

return ret;
}

 

[red floyd]

Hi,

I am thinking about using classes to encapsulate threads for my
application.

My requirements are the following:

The thread implementation sould not know what has to be implemented in
the
thread frunction nor it has to define an abstract method to force
implementation
in that. (Then the implementation could not be instantiated)

Why would you want to instantiate the base class?

What's wrong with:

class Thread
{
private:
virtual void thread_func() = 0;
static void start_thread(void* param)
{
static_cast<Thread*>(param)->thread_func();
}
void start()
{
os_specific_thread_starter(&start_thread, this);
}
protected:
Thread() { }
virtual ~Thread() { }
private:
Thread(const Thread&);
Thread& operator=(const Thread&);
};

Then you have the following:

class MyThread : public Thread
{
private:
int n;
public:
MyThread(int n_) : Thread(), n(n_) { }
~MyThread();
private:
void thread_func()
{
std::cout << "Hello from thread " << n << std::endl;
}
};

All you need to do is define thread_func.

 

[Gianni Mariani]

I'm not sure exactly what you're trying to say here.

Why would you want to instantiate the base class?

What's wrong with:

class Thread
{
private:
virtual void thread_func() = 0;
static void start_thread(void* param)
{
static_cast<Thread*>(param)->thread_func();
}
void start()
{
os_specific_thread_starter(&start_thread, this);
}
protected:
Thread() { }
virtual ~Thread() { }
private:
Thread(const Thread&);
Thread& operator=(const Thread&);
};

Then you have the following:

class MyThread : public Thread
{
private:
int n;
public:
MyThread(int n_) : Thread(), n(n_) { }
~MyThread();
private:
void thread_func()
{
std::cout << "Hello from thread " << n << std::endl;
}
};

All you need to do is define thread_func.

a) Need synchronization in destructor
b) Must not be copy constructible or assignable

 

[red floyd]

a) Need synchronization in destructor

Left as exercise for the reader. Note that this is really skeleton
code, no error checking etc... It's just "here's the concept" pseudo-code.

b) Must not be copy constructible or assignable

Agreed. I did it in the base, but not the child. Shown as an example.
However, since the base has private unimplemented copy/assignment, the
default copy/assignment for the child should fail, correct?

 

[Noah Roberts]

Hi,

I am thinking about using classes to encapsulate threads for my
application.

Try boost::thread

 

[Gianni Mariani]

Gianni Mariani wrote: ....

Agreed. I did it in the base, but not the child. Shown as an example.
However, since the base has private unimplemented copy/assignment, the
default copy/assignment for the child should fail, correct?

I missed that - you're correct.

 

[Michael DOUBEZ]

Lothar Behrens a écrit :

Hi,

I am thinking about using classes to encapsulate threads for my
application.

My requirements are the following:

The thread implementation sould not know what has to be implemented in
the
thread frunction nor it has to define an abstract method to force
implementation
in that. (Then the implementation could not be instantiated)

Also the implementation should not derive from the thread class or
their interface.
(No direct dependencies by linking against the threading library)

That given, I would be able to late bind the real thread
implementation by runtime loading
the instance from any DLL / so module.

My understanding is that you want to define an abstract factory for your
threading object (you might add condition and mutexes).

Typical samples of a thread class using a static member fuction. But I
prefer to
use a member callback for that. This way I could separate a specific
thread
implementation from the thread base class and also use dynamic loading
of this
class.

The two are equivalent, you may as well start with a static function and
then make wrappers to call member functions.

In the sample here I have leaved the static member function to be
called at first level.

The trick here I also use on other member callback issues in my
application is a typedef
and store both, the instance to the implementation and the pointer to
the given member
function.

Is there any issue, that let invalidate my concept ?
[snip code]
lbErrCodes run();
lbErrCodes stop();
lbErrCodes pause();
lbErrCodes resume();

You may not be able to implement all functions on all plateform (there
is not always a way to stop a thread).

Michael

 

[Chris Thomasson]

Hi,

I am thinking about using classes to encapsulate threads for my
application.

[...]

Here is a very brief outline for a possible CO++ threading scheme...

http://groups.google.com/group/comp.lang.c++.moderated/msg/679c36e0e1123ece

;^)

 

[kwikius]

Hi,

I am thinking about using classes to encapsulate threads for my
application.

[...]

Here is a very brief outline for a possible CO++ threading scheme...

http://groups.google.com/group/comp.lang.c++.moderated/msg/679c36e0e1...

;^)

FWIW to provide some contrast, there is a fair amount of activity
related to standardising concurrency in the next generation of C++.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2169.html

(Head down to the "Active topics in Evolution" section on the page,
where most of the proposals seem to be).

regards
Andy Little