Re: [pclasses-devel] questions about thread model...

[Christian P. <cp...@se...>]

Am Montag 20 Dezember 2004 02:27 schrieb stephan beal:
> Yo again,
>
> i'm looking through the thread docs, and a couple things aren't clear to
> me:
>
> - What is the conceptual difference between ThreadJob and Thread? It
> seems that ThreadJob is a simplified form of Thread?

ThreadJob objects are used by the ThreadPool to do the actual work that is 
enqueued to the ThreadPool. 

> - i think ThreadJob's ctor is broken:
>   ThreadJob(ThreadPool *p)
> Subclasses of ThreadJob which call this ctor will be queued into p
> before they are actually finished construction, which means they may
> (?) begin execution before they are completely finished constructing.

You're right ... it's racy :-(
Under high load (an app that spawns hundred of Threads) the Thread class is 
also racy. However i've written a new, simple, more lightwight Thread class 
for the use in the next major version.

> What i want to do is be able to start N apps in my framework and keep
> track of them in some container. When a thread dies (app is closed)
> i'll need to update my container, which i can do via Thread::final()
> (it would seems) and by locking the container.
>
>
> What i'm not clear on is whether i should use Thread or ThreadJob as a
> basis for doing this. Also, what would be the most straightforward way
> to lock a container using P's API? (i have almost no experience with
> MT, mutexes, etc.)

I would use Thread in this case. 
For locking you could exclusive the access to the container by using a 
CriticalSection, Mutex, RWLock or Semaphore. Which one you should use depends 
on your needs.

<code>
list<String> l;
CriticalSection cs;
CriticalSection::Lock lck(cs);
l.push_back('hallo welt');
</code>

<code>
CriticalSection::Lock lck(cs);
for(list<String>::iterator i = l.begin(); i != l.end(); i++)
{
 /* .. */
}
</code>

CriticalSection::Lock is a Lock guard, which locks the CriticalSection upon 
construction, and releases it when destructing.

The missing of thread-safe containers are the reason why i would like to 
implement Containers into P. I have some nice ideas which, when done right, 
could automatically Lock the Container if you're iterating over it. Locking 
is a huge overhead when not using MT, so i decided to add LockTraits to P 
which will allow you to instantiate Container with and without locking.

Imagine the following:

<code>
List<String, RWLock> l;
l.push_back('hallo welt')   /* acquires a WriteLock before pushing back */

for(list<String>:const_iterator i = l.begin(); i != l.end(); i++) 
/* aquires a ReadLock */
{
 /* .. */
}

for(list<String>:iterator i = l.begin(); i != l.end(); i++) 
/* aquires a WriteLock */
{
 /* .. */
}
</code>

You could also write:
List<String,Mutex> l;    (uses a Mutex to do the locking)
or:
List<String> l;  (which uses no locking at all)


What do you think ?
Many c++ programmers don't like the idea of own container implementations - 
instead one would stick with STL ones, which are, in my opinion not powerfull 
enough.

Would you like to have a copy of the experimental code ? 
I could setup a temporary cvs server for it.


Have a nice day,

Christian