passing arguments to pthreads

passing arguments to pthreads

[Daniel Hilst Selli]

Hi, I have a question about passing multiple arguments to pthreads, the 
big deal is where the paremeters are kept.. I see two possible 
solutions.. keep it on static variables that are never deallocated.. or 
on heap.. so here is my first question

Passing local (stack) variables as arguments to thread is trouble, since 
the scope of this variables can go away before my thread returns..right? 
So forget about local variables

So here is the two options I see, static vs heap...
I'm using this model on one of my applications, is the same senario, a 
function that receives 3 ints as arguments and is called as a thread.. I 
create a little wrapper... here is the code http://pastebin.com/Air7u0YD


How gurus does this? I free the args on threadfd wrapper since, on my 
real application can't join the thread, to be honest, is and deatached 
thread.. Is there something wrong with this strategy, it seems ugly to 
me....

Cheers,

Re: passing arguments to pthreads

[Celelibi]

2014-03-14 16:08 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
> Hi, I have a question about passing multiple arguments to pthreads, the
> big deal is where the paremeters are kept.. I see two possible
> solutions.. keep it on static variables that are never deallocated.. or
> on heap.. so here is my first question
>
> Passing local (stack) variables as arguments to thread is trouble, since
> the scope of this variables can go away before my thread returns..right?
> So forget about local variables
>
> So here is the two options I see, static vs heap...
> I'm using this model on one of my applications, is the same senario, a
> function that receives 3 ints as arguments and is called as a thread.. I
> create a little wrapper... here is the code http://pastebin.com/Air7u0YD
>
>
> How gurus does this? I free the args on threadfd wrapper since, on my
> real application can't join the thread, to be honest, is and deatached
> thread.. Is there something wrong with this strategy, it seems ugly to
> me....
>
> Cheers,

Hello,

If you don't mind making the start time of the threads a bit slower,
you can make every thread copy its data into its local stack.
You can either allocate one set of arguments on the stack of the main
and then, with a semaphore wait for the thread to copy its data before
erasing it with the data for the second thread and so on.
Or you can allocate enough memory for the arguments of all the
threads, start all the threads, and still with a semaphore wait that
all the threads copied their own data to their stack.

You can also make something in-between by allocating enough memory for
a fixed number of arguments. But it's becoming complicated to handle
for probably no gain.

But actually, I don't really see why you wouldn't join the threads.
You must not terminate the function main while the threads are
running. If you do, all the threads will be terminated.


Celelibi

Re: passing arguments to pthreads

[Daniel Hilst Selli]

On 03/14/2014 12:46 PM, Celelibi wrote:
> 2014-03-14 16:08 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
>> Hi, I have a question about passing multiple arguments to pthreads, the
>> big deal is where the paremeters are kept.. I see two possible
>> solutions.. keep it on static variables that are never deallocated.. or
>> on heap.. so here is my first question
>>
>> Passing local (stack) variables as arguments to thread is trouble, since
>> the scope of this variables can go away before my thread returns..right?
>> So forget about local variables
>>
>> So here is the two options I see, static vs heap...
>> I'm using this model on one of my applications, is the same senario, a
>> function that receives 3 ints as arguments and is called as a thread.. I
>> create a little wrapper... here is the code http://pastebin.com/Air7u0YD
>>
>>
>> How gurus does this? I free the args on threadfd wrapper since, on my
>> real application can't join the thread, to be honest, is and deatached
>> thread.. Is there something wrong with this strategy, it seems ugly to
>> me....
>>
>> Cheers,
>
> Hello,
>
> If you don't mind making the start time of the threads a bit slower,
> you can make every thread copy its data into its local stack.
> You can either allocate one set of arguments on the stack of the main
> and then, with a semaphore wait for the thread to copy its data before
> erasing it with the data for the second thread and so on.
> Or you can allocate enough memory for the arguments of all the
> threads, start all the threads, and still with a semaphore wait that
> all the threads copied their own data to their stack.
Making parameters local to threads seems an elegant solution for me, how 
would I do it? Should I use this? 
http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_getspecific.html


>
> You can also make something in-between by allocating enough memory for
> a fixed number of arguments. But it's becoming complicated to handle
> for probably no gain.
This seems what I'm doing right now.. For simple cases seems acceptable 
but for complex case, it seems to be trouble to handle...

>
> But actually, I don't really see why you wouldn't join the threads.
> You must not terminate the function main while the threads are
> running. If you do, all the threads will be terminated.
I have this cenario, I'm wrinting a layer that will sit between an 
industrial stack and end user (a programmer)... the stack will call my 
callback for any events that ocurr, my callback should forward the call 
to user's callback based on event, in other words, my layer will handle 
some events, others are passed to user.. The problem is that the stack 
call my callback from its context and this blocks stack execution until 
my callback returns, this is the reason I'm creating a new thread in 
first place.. I can't trust user to return fast, I can't wait for it.. 
this is why I'm not joining the thread...

Thanks for your help :-)

Cheers...
>
>
> Celelibi
>

Re: passing arguments to pthreads

[Celelibi]

2014-03-14 18:30 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
> On 03/14/2014 12:46 PM, Celelibi wrote:
>> 2014-03-14 16:08 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
>>> Hi, I have a question about passing multiple arguments to pthreads, the
>>> big deal is where the paremeters are kept.. I see two possible
>>> solutions.. keep it on static variables that are never deallocated.. or
>>> on heap.. so here is my first question
>>>
>>> Passing local (stack) variables as arguments to thread is trouble, since
>>> the scope of this variables can go away before my thread returns..right?
>>> So forget about local variables
>>>
>>> So here is the two options I see, static vs heap...
>>> I'm using this model on one of my applications, is the same senario, a
>>> function that receives 3 ints as arguments and is called as a thread.. I
>>> create a little wrapper... here is the code http://pastebin.com/Air7u0YD
>>>
>>>
>>> How gurus does this? I free the args on threadfd wrapper since, on my
>>> real application can't join the thread, to be honest, is and deatached
>>> thread.. Is there something wrong with this strategy, it seems ugly to
>>> me....
>>>
>>> Cheers,
>>
>> Hello,
>>
>> If you don't mind making the start time of the threads a bit slower,
>> you can make every thread copy its data into its local stack.
>> You can either allocate one set of arguments on the stack of the main
>> and then, with a semaphore wait for the thread to copy its data before
>> erasing it with the data for the second thread and so on.
>> Or you can allocate enough memory for the arguments of all the
>> threads, start all the threads, and still with a semaphore wait that
>> all the threads copied their own data to their stack.
> Making parameters local to threads seems an elegant solution for me, how
> would I do it? Should I use this?
> http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_getspecific.html

I didn't know about pthread_getspecific. But it seems that they only
store void*. Not very useful to replace function arguments.

I'd just suggest starting your thread routine with something like:
struct thread_arg *a = arg;
int a1  = a->a1;
int a2  = a->a2;
int a3  = a->a3;
sem_post(a->sem);

>
>
>>
>> You can also make something in-between by allocating enough memory for
>> a fixed number of arguments. But it's becoming complicated to handle
>> for probably no gain.
> This seems what I'm doing right now.. For simple cases seems acceptable
> but for complex case, it seems to be trouble to handle...
>
>>
>> But actually, I don't really see why you wouldn't join the threads.
>> You must not terminate the function main while the threads are
>> running. If you do, all the threads will be terminated.
> I have this cenario, I'm wrinting a layer that will sit between an
> industrial stack and end user (a programmer)... the stack will call my
> callback for any events that ocurr, my callback should forward the call
> to user's callback based on event, in other words, my layer will handle
> some events, others are passed to user.. The problem is that the stack
> call my callback from its context and this blocks stack execution until
> my callback returns, this is the reason I'm creating a new thread in
> first place.. I can't trust user to return fast, I can't wait for it..
> this is why I'm not joining the thread...

Are you sure you need threads? And not just a way to postpone a long
function call until you have time to actually call it?

I mean: introducing threads when you don't really need to perform
several CPU-intensive actions at the very same time is not always
worth it.
Although the idea might seem sexy in the begining, it always lead to
synchronization problems. And bugs with threaded programs are just
harder to spot and to fix.


Celelibi

Re: passing arguments to pthreads

[Daniel Hilst Selli]

On 03/14/2014 04:22 PM, Celelibi wrote:
> 2014-03-14 18:30 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
>> On 03/14/2014 12:46 PM, Celelibi wrote:
>>> 2014-03-14 16:08 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
>>>> Hi, I have a question about passing multiple arguments to pthreads, the
>>>> big deal is where the paremeters are kept.. I see two possible
>>>> solutions.. keep it on static variables that are never deallocated.. or
>>>> on heap.. so here is my first question
>>>>
>>>> Passing local (stack) variables as arguments to thread is trouble, since
>>>> the scope of this variables can go away before my thread returns..right?
>>>> So forget about local variables
>>>>
>>>> So here is the two options I see, static vs heap...
>>>> I'm using this model on one of my applications, is the same senario, a
>>>> function that receives 3 ints as arguments and is called as a thread.. I
>>>> create a little wrapper... here is the code http://pastebin.com/Air7u0YD
>>>>
>>>>
>>>> How gurus does this? I free the args on threadfd wrapper since, on my
>>>> real application can't join the thread, to be honest, is and deatached
>>>> thread.. Is there something wrong with this strategy, it seems ugly to
>>>> me....
>>>>
>>>> Cheers,
>>>
>>> Hello,
>>>
>>> If you don't mind making the start time of the threads a bit slower,
>>> you can make every thread copy its data into its local stack.
>>> You can either allocate one set of arguments on the stack of the main
>>> and then, with a semaphore wait for the thread to copy its data before
>>> erasing it with the data for the second thread and so on.
>>> Or you can allocate enough memory for the arguments of all the
>>> threads, start all the threads, and still with a semaphore wait that
>>> all the threads copied their own data to their stack.
>> Making parameters local to threads seems an elegant solution for me, how
>> would I do it? Should I use this?
>> http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_getspecific.html
>
> I didn't know about pthread_getspecific. But it seems that they only
> store void*. Not very useful to replace function arguments.
>
> I'd just suggest starting your thread routine with something like:
> struct thread_arg *a = arg;
> int a1  = a->a1;
> int a2  = a->a2;
> int a3  = a->a3;
> sem_post(a->sem);
I'm not using semaphores here, I just create a wrapper over the real 
function I want to call with as 3 ints as arguments, something like this

main()
{
   int *args = malloc(sizeof(int) * 3);
   args[0] = x; args[1] = y; args[2] = z;
   pthread_create(th, detached, wrap, args)
}

void *wrap(void *args)
{
   real_func(args[0], args[1], args[2]);
   free(args);
}


The args are only freed when real_func returns, so I don't see problems 
and need to use semaphores, did you? Is just this function that I 
execute as a thread, all others on my layer follow a normal flow, I 
mean, no parallel stuff...


>
>>
>>
>>>
>>> You can also make something in-between by allocating enough memory for
>>> a fixed number of arguments. But it's becoming complicated to handle
>>> for probably no gain.
>> This seems what I'm doing right now.. For simple cases seems acceptable
>> but for complex case, it seems to be trouble to handle...
>>
>>>
>>> But actually, I don't really see why you wouldn't join the threads.
>>> You must not terminate the function main while the threads are
>>> running. If you do, all the threads will be terminated.
>> I have this cenario, I'm wrinting a layer that will sit between an
>> industrial stack and end user (a programmer)... the stack will call my
>> callback for any events that ocurr, my callback should forward the call
>> to user's callback based on event, in other words, my layer will handle
>> some events, others are passed to user.. The problem is that the stack
>> call my callback from its context and this blocks stack execution until
>> my callback returns, this is the reason I'm creating a new thread in
>> first place.. I can't trust user to return fast, I can't wait for it..
>> this is why I'm not joining the thread...
>
> Are you sure you need threads? And not just a way to postpone a long
> function call until you have time to actually call it?
>
> I mean: introducing threads when you don't really need to perform
> several CPU-intensive actions at the very same time is not always
> worth it.
> Although the idea might seem sexy in the begining, it always lead to
> synchronization problems. And bugs with threaded programs are just
> harder to spot and to fix.
I agree, I don't like threads when they aren't needed too, but as a 
layer I have no control on execution flow, and, the stack is already 
full of threads..

Still I'm wondering how to postpone this execution, I can execute a 
signal handler as an alarm or something, but it seems as ugly as threads...

Thanks for your answer :-)
Cheers,
>
>
> Celelibi
>

Re: passing arguments to pthreads

[Celelibi]

2014-03-18 23:21 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
> On 03/14/2014 04:22 PM, Celelibi wrote:
>> 2014-03-14 18:30 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
>>> On 03/14/2014 12:46 PM, Celelibi wrote:
>>>> 2014-03-14 16:08 UTC+01:00, Daniel Hilst Selli <danielhilst@gmail.com>:
>>>>> Hi, I have a question about passing multiple arguments to pthreads,
>>>>> the
>>>>> big deal is where the paremeters are kept.. I see two possible
>>>>> solutions.. keep it on static variables that are never deallocated..
>>>>> or
>>>>> on heap.. so here is my first question
>>>>>
>>>>> Passing local (stack) variables as arguments to thread is trouble,
>>>>> since
>>>>> the scope of this variables can go away before my thread
>>>>> returns..right?
>>>>> So forget about local variables
>>>>>
>>>>> So here is the two options I see, static vs heap...
>>>>> I'm using this model on one of my applications, is the same senario, a
>>>>> function that receives 3 ints as arguments and is called as a thread..
>>>>> I
>>>>> create a little wrapper... here is the code
>>>>> http://pastebin.com/Air7u0YD
>>>>>
>>>>>
>>>>> How gurus does this? I free the args on threadfd wrapper since, on my
>>>>> real application can't join the thread, to be honest, is and deatached
>>>>> thread.. Is there something wrong with this strategy, it seems ugly to
>>>>> me....
>>>>>
>>>>> Cheers,
>>>>
>>>> Hello,
>>>>
>>>> If you don't mind making the start time of the threads a bit slower,
>>>> you can make every thread copy its data into its local stack.
>>>> You can either allocate one set of arguments on the stack of the main
>>>> and then, with a semaphore wait for the thread to copy its data before
>>>> erasing it with the data for the second thread and so on.
>>>> Or you can allocate enough memory for the arguments of all the
>>>> threads, start all the threads, and still with a semaphore wait that
>>>> all the threads copied their own data to their stack.
>>> Making parameters local to threads seems an elegant solution for me, how
>>> would I do it? Should I use this?
>>> http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_getspecific.html
>>
>> I didn't know about pthread_getspecific. But it seems that they only
>> store void*. Not very useful to replace function arguments.
>>
>> I'd just suggest starting your thread routine with something like:
>> struct thread_arg *a = arg;
>> int a1  = a->a1;
>> int a2  = a->a2;
>> int a3  = a->a3;
>> sem_post(a->sem);
> I'm not using semaphores here, I just create a wrapper over the real
> function I want to call with as 3 ints as arguments, something like this
>
> main()
> {
>    int *args = malloc(sizeof(int) * 3);
>    args[0] = x; args[1] = y; args[2] = z;
>    pthread_create(th, detached, wrap, args)
> }
>
> void *wrap(void *args)
> {
>    real_func(args[0], args[1], args[2]);
>    free(args);
> }

You need to cast args as int*.


> The args are only freed when real_func returns, so I don't see problems
> and need to use semaphores, did you? Is just this function that I
> execute as a thread, all others on my layer follow a normal flow, I
> mean, no parallel stuff...

I thought you wanted to avoid using the heap.
Isn't that code more or less what you had in the pastbin in your first message?
Moreover, there are other way of terminating a thread. pthread_cancel
for instance.

But... Do your threads terminate? I thought you didn't wanted to join them.


>> Are you sure you need threads? And not just a way to postpone a long
>> function call until you have time to actually call it?
>>
>> I mean: introducing threads when you don't really need to perform
>> several CPU-intensive actions at the very same time is not always
>> worth it.
>> Although the idea might seem sexy in the begining, it always lead to
>> synchronization problems. And bugs with threaded programs are just
>> harder to spot and to fix.
> I agree, I don't like threads when they aren't needed too, but as a
> layer I have no control on execution flow, and, the stack is already
> full of threads..
>
> Still I'm wondering how to postpone this execution, I can execute a
> signal handler as an alarm or something, but it seems as ugly as threads...
>

You're writing a layer between some user code and some backend that
generate events (you called "the industrial stack"). Right?
What does the main thread executes? Where is the main loop?
You may provide a function to the user code that the user code has to
call every once is a while. Similar to what GTK does with
gtk_main_iteration. This function would process any pending event and
call the callback functions. And if the user code do not want to
handle the main loop, you can provide a function that loops on that
even-processing function. Just like gtk_main.

However, if the main loop of the code is in the backend, then maybe
they provide an "idle event". It's a callback that is called when
there is no other event.

But if you say the backend is already full of threads... Then adding
more may not add much troubles. And if the backend is full of threads,
is that really important that you return to the caller ASAP?


Celelibi