Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Macro for pthread_create()

Reply
Thread Tools

Macro for pthread_create()

 
 
Jens Thoms Toerring
Guest
Posts: n/a
 
      01-10-2012
daniele.g <(E-Mail Removed)> wrote:
> Seebs <(E-Mail Removed)> writes:


> > The obvious thing that leaps out at me is that you say you want
> > pthread_create(&func_id, NULL, func, (void *) param)
> > but you wrote
> > pthread_create(&func, NULL, func, (void *) param)
> >
> > Which makes me wonder whether you actually wanted the _id, and if so,
> > why you omitted it. You may be looking for the "token pasting" operator,
> > ##. See the comp.lang.c FAQ for more info on that.


> Yur're right, I wrote wrong the macro expansion.
> What I want is that when I compile this source under linux the macro is
> translated into the pthread_create(...) function, knowing that the macro
> has only two parameters. My problem is that I don't know how to create
> dinamically a func_id to be inserted into the macro definition.


If you never need to use the thread ID (i.e. what's returned via
the first argument) perhaps this is what you're looking for:

#define THREAD( func, parm ) \
{ pthread_t thread_id; \
pthread_create( &thread_id, NULL, func, ( void * ) ( parm ) ); }

The curly braces are just there for restricting the life-time
of the 'thread_id' variable (it "goes out of scope" at the
closing '}').

But if you need the thread ID later on then I guess you will
have to explain in more detail what this is all about (or what
you exactly mean with "dynamically create a func_id").

Regards, Jens
--
\ Jens Thoms Toerring ___ http://www.velocityreviews.com/forums/(E-Mail Removed)
\__________________________ http://toerring.de
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      01-10-2012
On 1/10/2012 5:01 PM, daniele.g wrote:
>[...]
> Yur're right, I wrote wrong the macro expansion.
> What I want is that when I compile this source under linux the macro is
> translated into the pthread_create(...) function, knowing that the macro
> has only two parameters. My problem is that I don't know how to create
> dinamically a func_id to be inserted into the macro definition.


You'd need to generate both the declaration and the use:

#define THREAD(func,parm) { \
pthread_t func ## _id; \
pthread_create(&func ## _id, NULL, func, (void*)(parm)); \
}

Under C99 or later, which allow variable declarations to be
intermixed with executable statements, you can get rid of the
curly braces.

<off-topic>

... but it's a dumb idea. The pthread_t variable is your only
"handle" for the new thread, something you'll need if you later
want to await the thread's completion or send it a signal or anything
of that kind. It's a vital part of the machinery, not something that
should be swept under the rug.

Also, the presence of the declaration means that the macro
expansion is no longer an expression (it's a declaration plus an
expression-statement, possibly wrapped in a compound statement).
Since it's not an expression it has no value, meaning that the value
returned by pthread_create() is simply lost: You have no way of
knowing whether thread creation succeeded or failed, and no clue
as to the cause of a failure.

Why do you think such a macro would be desirable?

</off-topic>

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      01-10-2012
On 01/11/12 11:01 AM, daniele.g wrote:
> Seebs<(E-Mail Removed)> writes:
>
>> The obvious thing that leaps out at me is that you say you want
>> pthread_create(&func_id, NULL, func, (void *) param)
>> but you wrote
>> pthread_create(&func, NULL, func, (void *) param)
>>
>> Which makes me wonder whether you actually wanted the _id, and if so,
>> why you omitted it. You may be looking for the "token pasting" operator,
>> ##. See the comp.lang.c FAQ for more info on that.

>
> Yur're right, I wrote wrong the macro expansion.
> What I want is that when I compile this source under linux the macro is
> translated into the pthread_create(...) function, knowing that the macro
> has only two parameters. My problem is that I don't know how to create
> dinamically a func_id to be inserted into the macro definition.


Why use a macro? It would be easier and clearer to use a function.

--
Ian Collins
 
Reply With Quote
 
daniele.g
Guest
Posts: n/a
 
      01-10-2012
Eric Sosman <(E-Mail Removed)> writes:

> <Off-topic>
>
> ... But it's a dumb idea. The pthread_t variable is your only
> "handle" for the new thread, something you'll need if you later
> want to await the thread's completion or send it a signal or anything
> of that kind. It's a vital part of the machinery, not something that
> should be swept under the rug.


I do agree.

> Also, the presence of the declaration means that the macro
> expansion is no longer an expression (it's a declaration plus an
> expression-statement, possibly wrapped in a compound statement).
> Since it's not an expression it has no value, meaning that the value
> returned by pthread_create() is simply lost: You have no way of
> knowing whether thread creation succeeded or failed, and no clue
> as to the cause of a failure.
>
> Why do you think such a macro would be desirable?


That macro would be desiderable because I need to make it run under
Linux and another OS for embedded systems which doesn't support
pthreads. For now I want it run under Linux for testing. Maybe the macro
is badly defined, and need to be modified.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-10-2012
On 01/10/2012 06:04 PM, daniele.g wrote:
> Eric Sosman <(E-Mail Removed)> writes:
>
>> <Off-topic>
>>
>> ... But it's a dumb idea. The pthread_t variable is your only
>> "handle" for the new thread, something you'll need if you later
>> want to await the thread's completion or send it a signal or anything
>> of that kind. It's a vital part of the machinery, not something that
>> should be swept under the rug.

>
> I do agree.
>
>> Also, the presence of the declaration means that the macro
>> expansion is no longer an expression (it's a declaration plus an
>> expression-statement, possibly wrapped in a compound statement).
>> Since it's not an expression it has no value, meaning that the value
>> returned by pthread_create() is simply lost: You have no way of
>> knowing whether thread creation succeeded or failed, and no clue
>> as to the cause of a failure.
>>
>> Why do you think such a macro would be desirable?

>
> That macro would be desiderable because I need to make it run under
> Linux and another OS for embedded systems which doesn't support
> pthreads. For now I want it run under Linux for testing. Maybe the macro
> is badly defined, and need to be modified.


To understand why a macro is needed, it would help to know how you were
thinking of defining the macro for the other OS. It's possible that
providing two different function definitions, depending upon the OS
(possibly with two different declarations) might be clearer and safer
than providing two different macro definitions.

The macro as you've presented it has one clear advantage: it enforces a
naming convention connecting the function and and the thread id.
However, it might be better to maintain that connection by other means,
such as a structure containing both the thread id and a pointer to the
relevant function.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-10-2012
Ben Bacarisse <(E-Mail Removed)> writes:
> (E-Mail Removed) (daniele.g) writes:
>> Seebs <(E-Mail Removed)> writes:
>>> The obvious thing that leaps out at me is that you say you want
>>> pthread_create(&func_id, NULL, func, (void *) param)
>>> but you wrote
>>> pthread_create(&func, NULL, func, (void *) param)
>>>
>>> Which makes me wonder whether you actually wanted the _id, and if so,
>>> why you omitted it. You may be looking for the "token pasting" operator,
>>> ##. See the comp.lang.c FAQ for more info on that.

>>
>> Yur're right, I wrote wrong the macro expansion.
>> What I want is that when I compile this source under linux the macro is
>> translated into the pthread_create(...) function, knowing that the macro
>> has only two parameters. My problem is that I don't know how to create
>> dinamically a func_id to be inserted into the macro definition.

>
> If there is a fixed, textual, relationship between "func" and "func_id"
> (i.e. the first parameter is always the third but with _id added to the
> name) then the token pasting macro already posted (it uses "func ## _id"
> in the body) will do the trick.


Of course you have to declare "func" and "func_id", or "foo" and
"foo_id", or ....

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-10-2012
(E-Mail Removed) (Jens Thoms Toerring) writes:
[...]
> If you never need to use the thread ID (i.e. what's returned via
> the first argument) perhaps this is what you're looking for:
>
> #define THREAD( func, parm ) \
> { pthread_t thread_id; \
> pthread_create( &thread_id, NULL, func, ( void * ) ( parm ) ); }
>
> The curly braces are just there for restricting the life-time
> of the 'thread_id' variable (it "goes out of scope" at the
> closing '}').

[...]

A macro that expands to a statement should use the "do { ... } while
(0)" idiom:

#define THREAD( func, parm ) \
do { \
pthread_t thread_id; \
pthread_create( &thread_id, NULL, (func), ( void * ) ( parm ) ); \
while (0)


--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-10-2012
On 1/10/2012 6:04 PM, daniele.g wrote:
> Eric Sosman<(E-Mail Removed)> writes:
>> [...]
>> Why do you think such a macro would be desirable?

>
> That macro would be desiderable because I need to make it run under
> Linux and another OS for embedded systems which doesn't support
> pthreads. For now I want it run under Linux for testing. Maybe the macro
> is badly defined, and need to be modified.


It seems likely that simulating threads on an unthreaded
system (or even just doing without them) will involve more changes
to your program than you can easily encapsulate in a macro. The
purely-C question of how to write the macro has been answered, but
the beyond-C issues of managing the threading aren't really this
forum's business[*]. Try comp.programming.threads.
[*] The latest "C11" edition of the C Standard defines threading
support for C, so at least some threading questions will eventually
become topical here. But C11 is so fresh from the womb that its eyes
aren't yet open, so it'll be a while before you can find C11-conforming
implementations or get reliable advice on using them.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
daniele.g
Guest
Posts: n/a
 
      01-11-2012
Ian Collins <(E-Mail Removed)> writes:

> On 01/11/12 11:01 AM, daniele.g wrote:
>> Seebs<(E-Mail Removed)> writes:
>>
>>> The obvious thing that leaps out at me is that you say you want
>>> pthread_create(&func_id, NULL, func, (void *) param)
>>> but you wrote
>>> pthread_create(&func, NULL, func, (void *) param)
>>>
>>> Which makes me wonder whether you actually wanted the _id, and if so,
>>> why you omitted it. You may be looking for the "token pasting" operator,
>>> ##. See the comp.lang.c FAQ for more info on that.

>>
>> Yur're right, I wrote wrong the macro expansion.
>> What I want is that when I compile this source under linux the macro is
>> translated into the pthread_create(...) function, knowing that the macro
>> has only two parameters. My problem is that I don't know how to create
>> dinamically a func_id to be inserted into the macro definition.

>
> Why use a macro? It would be easier and clearer to use a function.


How? I mean: in Linux I can simply write:

#include <pthread.h>
....
pthread_create( ... );

in OS20 I can't since it doesn't have them, so my idea is to make a
conditional compiling using a macro. Am I right?
--
Vado pazzo per i piani ben riusciti!
-- John `Hunnibal' Smith, "A-Team"
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-11-2012
On 01/11/12 10:09 PM, daniele.g wrote:
> Ian Collins<(E-Mail Removed)> writes:
>
>> On 01/11/12 11:01 AM, daniele.g wrote:
>>> Seebs<(E-Mail Removed)> writes:
>>>
>>>> The obvious thing that leaps out at me is that you say you want
>>>> pthread_create(&func_id, NULL, func, (void *) param)
>>>> but you wrote
>>>> pthread_create(&func, NULL, func, (void *) param)
>>>>
>>>> Which makes me wonder whether you actually wanted the _id, and if so,
>>>> why you omitted it. You may be looking for the "token pasting" operator,
>>>> ##. See the comp.lang.c FAQ for more info on that.
>>>
>>> Yur're right, I wrote wrong the macro expansion.
>>> What I want is that when I compile this source under linux the macro is
>>> translated into the pthread_create(...) function, knowing that the macro
>>> has only two parameters. My problem is that I don't know how to create
>>> dinamically a func_id to be inserted into the macro definition.

>>
>> Why use a macro? It would be easier and clearer to use a function.

>
> How? I mean: in Linux I can simply write:
>
> #include<pthread.h>
> ....
> pthread_create( ... );
>
> in OS20 I can't since it doesn't have them, so my idea is to make a
> conditional compiling using a macro. Am I right?


So on a POSIX platform, include <pthread.h>, for others write your own
versions of the threading functions.

Something like

#if defined HAVE_PTHREADS
# include <pthread.h>
#else
# if defined SOME_OS
typedef int pthread_t;
typedef struct { /* supported options */ } pthread_attr_t;
int pthread_create( pthread_t *restrict thread,
const pthread_attr_t* restrict attr,
void* (*start_routine)(void*), void* restrict arg );
# endif
#endif

--
Ian Collins
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Dedicated Macro or Normal Macro? John Ortt Digital Photography 5 11-22-2005 12:43 PM
Macro lens on a camera with a macro setting??? mitchell.chris@gmail.com Digital Photography 2 09-28-2005 07:55 AM
in S.E. Asia : Canon EOS 300d with 100 macro ED vs. Nikon D70 with Nikon 105 macro ? J. Cod Digital Photography 0 09-29-2004 05:46 AM
#define macro to enclose an older macro with strings Dead RAM C++ 20 07-14-2004 10:58 AM
macro name from macro? D Senthil Kumar C Programming 1 09-21-2003 07:02 PM



Advertisments