Create a thread not in runnable state in POSIX thread

Create a thread not in runnable state in POSIX thread

Post by Yao Q » Wed, 13 Jun 2007 22:43:49



In our program, we do not want child thread run once it is created. We
expect that parent thread invoke pthread_create to create child thread,
and parent thread could start the child thread some time later.

We try to suspend the child thread after the pthread_create, but we find
that the child thread is running when parent child is still in
pthread_create.

Is it possible that we could create a child thread, and run it later?

--
Yao Qi < XXXX@XXXXX.COM > GNU/Linux Developer
http://www.yqcomputer.com/

Chicken Little only has to be right once.
 
 
 

Create a thread not in runnable state in POSIX thread

Post by Casper H.S » Wed, 13 Jun 2007 23:20:09

Yao Qi < XXXX@XXXXX.COM > writes:


Threads do not have parent/child relation ships.


Correct.


No. Why do you want to do that?

You can create a child thread and make it go to sleep (wait on
a condition variable).

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

Create a thread not in runnable state in POSIX thread

Post by Yao Q » Thu, 14 Jun 2007 00:49:33

Casper H.S. Dik < XXXX@XXXXX.COM > writes:



We are doing a runtime analysis tool, so that we do not want to modify
the application's source code to make "child" thread wait on a condition
variable.

In this tool, when "parent" thread creates a "child" thread, we will
know the "child" thread id and calculate some thing. Before we get the
result, we do not want "child" thread to run.


--
Yao Qi < XXXX@XXXXX.COM > GNU/Linux Developer
http://www.yqcomputer.com/

Bill ? ;-)
-- From some postings on comp.os.linux.misc
 
 
 

Create a thread not in runnable state in POSIX thread

Post by Frank Cusa » Thu, 14 Jun 2007 01:52:11


Maybe you could interpose on pthread_create().

-frank
 
 
 

Create a thread not in runnable state in POSIX thread

Post by Eric Sosma » Thu, 14 Jun 2007 01:59:19

Yao Qi wrote On 06/12/07 11:49,:

Use a "wrapper" function of your own as the starting
point for the thread:

struct wrapped {
void* (*func)(void*); /* client's thread func */
void* arg; /* arg for client thread */
};

void *wrapper(void *arg) {
struct wrapped wp = arg;

/* wait for go-ahead: */
pthread_mutex_lock(&mutex);
while (! green_light)
pthread_cond_wait(&condvar, &mutex);
pthread_mutex_unlock(&mutex);

/* run the unmodified client thread: */
return wp->func(wp->arg);
}

... and use pthread_create() to start threads that run
your wrapper() function (with appropriate arguments)
instead of running the client function directly. There
is nothing magical about the function where a thread
begins execution; it's just an ordinary callable function.

--
XXXX@XXXXX.COM
 
 
 

Create a thread not in runnable state in POSIX thread

Post by Eric Sosma » Thu, 14 Jun 2007 02:45:11

Eric Sosman wrote On 06/12/07 12:59,:

Typo: Should have been `*wp' instead of just `wp'.

--
XXXX@XXXXX.COM
 
 
 

Create a thread not in runnable state in POSIX thread

Post by Yao Q » Thu, 14 Jun 2007 16:48:54

Eric Sosman < XXXX@XXXXX.COM > writes:



Yeah. It is a good way to wrap my function in this way. Thanks for
your help.


--
Yao Qi < XXXX@XXXXX.COM > GNU/Linux Developer
http://www.yqcomputer.com/

Lisp Users:
Due to the holiday next Monday, there will be no garbage collection.
 
 
 

Create a thread not in runnable state in POSIX thread

Post by Maxim Yego » Wed, 20 Jun 2007 22:13:17


http://www.yqcomputer.com/
gives you the answer:

<quote>
RATIONALE

A suggested alternative to pthread_create() would be to define two
separate operations: create and start. Some applications would find
such behavior more natural. Ada, in particular, separates the
"creation" of a task from its "activation".

Splitting the operation was rejected by the standard developers for
many reasons:

* The number of calls required to start a thread would increase from
one to two and thus place an additional burden on applications that do
not require the additional synchronization. The second call, however,
could be avoided by the additional complication of a start-up state
attribute.
* An extra state would be introduced: "created but not started". This
would require the standard to specify the behavior of the thread
operations when the target has not yet started executing.
* For those applications that require such behavior, it is possible to
simulate the two separate steps with the facilities that are currently
provided. The start_routine() can synchronize by waiting on a
condition variable that is signaled by the start operation.
</quote>