Own implementation of multithread

Dear all,

I am working on a multithread application.
I have already built the TCL using --enable-threads.

In c++ code, I am trying to create many threads, each thread will
create its own interpreter.
Each interpreter will need to eval a script.

For example,

void * func( void * null ){
Tcl_Interp* tcl_interp = Tcl_CreateInterp();
Tcl_Init(tcl_interp);
char * script = "set a 1\n"
"set b 2\n"
"puts $a\n"
"puts $b\n";
Tcl_EvalObjEx(tcl_interp, script , TCL_EVAL_GLOBAL);
delete tcl_interp;
}

int main (){
....
for (int i = 0; i < 10000; ++i)
pthread_create(&tid,NULL,func,NULL);
....
}

I would like to ask is this approach is wrong?

Stephen Lai

On Aug 28, 12:15 am, lkfstep...@gmail.com wrote:
>
> In c++ code, I am trying to create many threads, each thread will
> create its own interpreter.
> Each interpreter will need to eval a script.
> ...
> I would like to ask is this approach is wrong?

It is hard to say without further details on your constraints, but
when possible it is better to stay at script level as pervasively as
possible, simply because for coarse-granularity operations like
spawning a thread+interp, there's no added value (like speed) in doing
it at the low level, while there's added complexity.

Maybe you can elaborate: is there an external requirement preventing
you from doing the "master" part in a Tcl script using the Thread
package ?

-Alex

More portable would be to create your threads with
Tcl_CreateThread

As I don't see you using anyting other than default attributes for the
pthread_create.


Beyond that I agree with Alexandre andwonder if instead you can make
the main controlling flow of control Tcl, and just supply appropriate
compiled extensions where needed, using the Tcl Thread package.

There are a few useful pages on the wiki (wiki.tcl.tk) if you search
for threads. Including http://wiki.tcl.tk/1339 which has a 'cookbook'
for using threads at the Tcl level. There are also some gotchas given
in some of those pages and a nice page on threads vs. events that
_may_ make you reconsider the architecture of your application.

Ron.

lkfstephen@gmail.com wrote:
> Dear all,
>
> I am working on a multithread application.
> I have already built the TCL using --enable-threads.
>
> In c++ code, I am trying to create many threads, each thread will
> create its own interpreter.
> Each interpreter will need to eval a script.
>
> For example,
>
> void * func( void * null ){
> Tcl_Interp* tcl_interp = Tcl_CreateInterp();
> Tcl_Init(tcl_interp);
> char * script = "set a 1\n"
> "set b 2\n"
> "puts $a\n"
> "puts $b\n";
> Tcl_EvalObjEx(tcl_interp, script , TCL_EVAL_GLOBAL);
> delete tcl_interp;
> }
>
> int main (){
> ...
> for (int i = 0; i < 10000; ++i)
> pthread_create(&tid,NULL,func,NULL);
> ...
> }
>
> I would like to ask is this approach is wrong?
>
> Stephen Lai


--
Ron Fox
NSCL
Michigan State University
East Lansing, MI 48824-1321

lkfstephen@gmail.com wrote:
> Dear all,
>
> I am working on a multithread application.
> I have already built the TCL using --enable-threads.
>
> In c++ code, I am trying to create many threads, each thread will
> create its own interpreter.
> Each interpreter will need to eval a script.
>
> For example,
>
> void * func( void * null ){
> Tcl_Interp* tcl_interp = Tcl_CreateInterp();
> Tcl_Init(tcl_interp);
> char * script = "set a 1\n"
> "set b 2\n"
> "puts $a\n"
> "puts $b\n";
> Tcl_EvalObjEx(tcl_interp, script , TCL_EVAL_GLOBAL);
> delete tcl_interp;
> }

"delete tcl_interp" is almost certainly wrong. The correct way is:
Tcl_DeleteInterp(interp);

I also suggest not using a tcl prefix for most things. While it's
unlikely that tcl would ever define something with the name tcl_interp,
it's possible.


> int main (){
> ...
> for (int i = 0; i < 10000; ++i)
> pthread_create(&tid,NULL,func,NULL);
> ...
> }
>
> I would like to ask is this approach is wrong?
>
> Stephen Lai

You're creating 10000 threads. That's a lot of threads. Most systems
have a limit much less than that. You'll most likely run out RAM, due
to the stack space for each thread, and other data structures. You're
also neglecting to check for errors. I have a feeling your
pthread_create is returning an error before 10000.

There is a PTHREAD_THREADS_MAX that you might want to look into:
http://www.opengroup.org/onlinepubs/.../limits.h.html

There is a problem though with that approach though, and that problem is
that GNU/Linux doesn't define PTHREAD_THREADS_MAX, because it's not
fully POSIX compliant/compatible.


George

On Aug 27, 3:15 pm, lkfstep...@gmail.com wrote:

> I am working on a multithread application.
> I have already built the TCL using --enable-threads.
>
> In c++ code, I am trying to create many threads, each thread will
> create its own interpreter.
> Each interpreter will need to eval a script.

That is a fine methodology, and years ago was the only one.

It is my understanding, and I am anxious to have any wrong
understandings corrected, that you don't even need to compile
Tcl with --enable-threads, which is only necessary if Tcl
manages the threads and communication between them.

Donald Arseneau asnd@triumf.ca

Donald Arseneau wrote:
> It is my understanding, and I am anxious to have any wrong
> understandings corrected, that you don't even need to compile
> Tcl with --enable-threads, which is only necessary if Tcl
> manages the threads and communication between them.

That's wrong, because when Tcl's built unthreaded it uses some static
data allocation strategies (for things that are otherwise shared between
threads) that are deeply wrong when more than one thread is in use. When
built threaded, such additional locks as are required are added.

If you're using Tcl from multiple threads, you should use a
thread-enabled build. If you're wanting to do communication between
threads or scripted control of them, the Thread extension is commended
as providing the tools required. :-)

Donal.