Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15691 > unrolled thread

Macro for pthread_create()

Back to article view | Back to comp.lang.c

Contents

  Macro for pthread_create() daniele@father.nostromo.wy (daniele.g) - 2012-01-10 19:21 +0100
    Re: Macro for pthread_create() jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 19:02 +0000
      Re: Macro for pthread_create() jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 20:18 +0000
        Re: Macro for pthread_create() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-10 20:29 +0000
          Re: Macro for pthread_create() jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 21:03 +0000
    Re: Macro for pthread_create() James Kuyper <jameskuyper@verizon.net> - 2012-01-10 14:14 -0500
      Re: Macro for pthread_create() Seebs <usenet-nospam@seebs.net> - 2012-01-10 20:44 +0000
      Re: Macro for pthread_create() Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2012-01-13 07:18 -0800
    Re: Macro for pthread_create() Seebs <usenet-nospam@seebs.net> - 2012-01-10 19:15 +0000
      Re: Macro for pthread_create() daniele@mother.nostromo.wy (daniele.g) - 2012-01-10 23:01 +0100
        Re: Macro for pthread_create() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-10 22:23 +0000
          Re: Macro for pthread_create() Keith Thompson <kst-u@mib.org> - 2012-01-10 15:23 -0800
        Re: Macro for pthread_create() jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 22:27 +0000
          Re: Macro for pthread_create() Keith Thompson <kst-u@mib.org> - 2012-01-10 15:25 -0800
        Re: Macro for pthread_create() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 17:31 -0500
          Re: Macro for pthread_create() daniele@mother.nostromo.wy (daniele.g) - 2012-01-11 00:04 +0100
            Re: Macro for pthread_create() James Kuyper <jameskuyper@verizon.net> - 2012-01-10 18:17 -0500
            Re: Macro for pthread_create() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 18:29 -0500
        Re: Macro for pthread_create() Ian Collins <ian-news@hotmail.com> - 2012-01-11 11:54 +1300
          Re: Macro for pthread_create() daniele@father.nostromo.wy (daniele.g) - 2012-01-11 10:09 +0100
            Re: Macro for pthread_create() Ian Collins <ian-news@hotmail.com> - 2012-01-11 22:20 +1300
            Re: Macro for pthread_create() James Kuyper <jameskuyper@verizon.net> - 2012-01-11 11:26 -0500
              Re: Macro for pthread_create() daniele@father.nostromo.wy (daniele.g) - 2012-01-12 12:07 +0100
                Re: Macro for pthread_create() James Kuyper <jameskuyper@verizon.net> - 2012-01-12 09:19 -0500
                  Re: Macro for pthread_create() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-12 20:34 -0500
              Re: Macro for pthread_create() daniele@father.nostromo.wy (daniele.g) - 2012-01-12 11:52 +0100
            Re: Macro for pthread_create() Seebs <usenet-nospam@seebs.net> - 2012-01-11 18:46 +0000
              Re: Macro for pthread_create() blp@cs.stanford.edu (Ben Pfaff) - 2012-01-11 11:12 -0800

Page 2 of 2 — ← Prev page 1 [2]

#15736

On 01/11/12 10:09 PM, daniele.g wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> On 01/11/12 11:01 AM, daniele.g wrote:
>>> Seebs<usenet-nospam@seebs.net>   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

[toc] | [prev] | [next] | [standalone]

#15753

On 01/11/2012 04:09 AM, daniele.g wrote:
> Ian Collins <ian-news@hotmail.com> writes:
...
>> 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?

Not necessarily. In the places where your code would call
pthread_create() on linux, what do you want your code to do on OS20?

[toc] | [prev] | [next] | [standalone]

#15782

James Kuyper <jameskuyper@verizon.net> writes:

> On 01/11/2012 04:09 AM, daniele.g wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
> ...
>>> 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?
>
> Not necessarily. In the places where your code would call
> pthread_create() on linux, what do you want your code to do on OS20?

task_create(), this is its syntax:

extern task_t *task_create(
   task_function_t proc_func,   // pointer to the task's entry point.
   task_param_t proc_param,     // the parameter which will be passed into proc_func.
   const size_t stack_size,     // required stack size for the task, in bytes.
   const int priority,          // task's scheduling priority.
   const char *name,            // the name of the task.
   task_flags_t flags           // start status of the task.
);


-- 
  Ci sono poche donne oneste che non siano stanche del loro mestiere.
  		-- La Rochefoucauld, "Massime"

[toc] | [prev] | [next] | [standalone]

#15784

On 01/12/2012 06:07 AM, daniele.g wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> On 01/11/2012 04:09 AM, daniele.g wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>> ...
>>>> 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?
>>
>> Not necessarily. In the places where your code would call
>> pthread_create() on linux, what do you want your code to do on OS20?
> 
> task_create(), this is its syntax:
> 
> extern task_t *task_create(
>    task_function_t proc_func,   // pointer to the task's entry point.
>    task_param_t proc_param,     // the parameter which will be passed into proc_func.
>    const size_t stack_size,     // required stack size for the task, in bytes.
>    const int priority,          // task's scheduling priority.
>    const char *name,            // the name of the task.
>    task_flags_t flags           // start status of the task.
> );

That's a fairly complicated interface; I can't imagine what your macro
would look like, but I think it would be a nightmare, as a macro.

You're basically suggesting that a macro be defined as follows:

#if SOMETHING

#include <pthread.h>
#define THREAD(func,parm) \
          pthread_create(&func ## _id, NULL, func, (void *)parm)
#else

#include "something.h"
#define THREAD(func, parm) \
	thread_create(????)

#endif

Note that the macro has to take the same number of parameters in both
definitions. You might need to give it more parameters, so it can pass
more on to thread_create() - but then you need to decide what
pthread_create() should do, if anything, with those additional parameters.

An easier approach would be to design your own function that wraps
whichever of the two functions is appropriate, with an interface that
allows it to make proper use of either one:

In my_thread.h:
#if SOMETHING
#include <pthread.h>
struct my_thread_info
{
   // information you'll need to keep track of while using pthreads
};
#else
#include "something.h"
struct my_thread_info
{
    // information you'll need while using other library
};
#endif
your_return_type my_thread_create(
	struct thread_info* /* other parameters */);

in my_thread.c:

#include "my_thread.h"

my_return_type my_thread_create(
	struct my_thread_info* info /*, other parameters */
)
{
#if SOMETHING
	// Setup for call
	pthread_create(/* arguments for call */);
	// After call cleanup
#else
	// Setup for call
	thread_create(/* Arguments for call */);
	// After call cleanup
#endif
}

You'll need a lot of flexibility to make two different threading systems
look the same, and using a function gives you a lot more flexibility
than a macro - part of the reason is the "Setup" and "After" sections
shown above.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#15795

On 1/12/2012 9:19 AM, James Kuyper wrote:
> On 01/12/2012 06:07 AM, daniele.g wrote:
>> James Kuyper<jameskuyper@verizon.net>  writes:
>>
>>> On 01/11/2012 04:09 AM, daniele.g wrote:
>>>> Ian Collins<ian-news@hotmail.com>  writes:
>>> ...
>>>>> 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?
>>>
>>> Not necessarily. In the places where your code would call
>>> pthread_create() on linux, what do you want your code to do on OS20?
>>
>> task_create(), this is its syntax:
>>
>> extern task_t *task_create(
>>     task_function_t proc_func,   // pointer to the task's entry point.
>>     task_param_t proc_param,     // the parameter which will be passed into proc_func.
>>     const size_t stack_size,     // required stack size for the task, in bytes.
>>     const int priority,          // task's scheduling priority.
>>     const char *name,            // the name of the task.
>>     task_flags_t flags           // start status of the task.
>> );
>
> That's a fairly complicated interface; I can't imagine what your macro
> would look like, but I think it would be a nightmare, as a macro.
>
> You're basically suggesting that a macro be defined as follows:
>
> #if SOMETHING
>
> #include<pthread.h>
> #define THREAD(func,parm) \
>            pthread_create(&func ## _id, NULL, func, (void *)parm)
> #else
>
> #include "something.h"
> #define THREAD(func, parm) \
> 	thread_create(????)
>
> #endif
>
> Note that the macro has to take the same number of parameters in both
> definitions. You might need to give it more parameters, so it can pass
> more on to thread_create() - but then you need to decide what
> pthread_create() should do, if anything, with those additional parameters.
>
> An easier approach would be to design your own function that wraps
> whichever of the two functions is appropriate, with an interface that
> allows it to make proper use of either one:
>
> In my_thread.h:
> #if SOMETHING
> #include<pthread.h>
> struct my_thread_info
> {
>     // information you'll need to keep track of while using pthreads
> };
> #else
> #include "something.h"
> struct my_thread_info
> {
>      // information you'll need while using other library
> };
> #endif
> your_return_type my_thread_create(
> 	struct thread_info* /* other parameters */);
>
> in my_thread.c:
>
> #include "my_thread.h"
>
> my_return_type my_thread_create(
> 	struct my_thread_info* info /*, other parameters */
> )
> {
> #if SOMETHING
> 	// Setup for call
> 	pthread_create(/* arguments for call */);
> 	// After call cleanup
> #else
> 	// Setup for call
> 	thread_create(/* Arguments for call */);
> 	// After call cleanup
> #endif
> }
>
> You'll need a lot of flexibility to make two different threading systems
> look the same, and using a function gives you a lot more flexibility
> than a macro - part of the reason is the "Setup" and "After" sections
> shown above.

     I'll second James' recommendation: Differences in threading
schemes are almost certainly too drastic to hide inside a macro,
or even a set of macros.  You'll need the full power of the C
language, not just a macro's power of textual substitution.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15783

James Kuyper <jameskuyper@verizon.net> writes:

> On 01/11/2012 04:09 AM, daniele.g wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
> ...
>>> 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?
>
> Not necessarily. In the places where your code would call
> pthread_create() on linux, what do you want your code to do on OS20?

It has a os20_task_create() function, which I really don't yet know how
it works, I will have to manage it in a second time.
-- 
  I ragazzi dell'85 sono strani.  Ne ho visto uno rubare la droga per
  comprarsi un'autoradio.
  		-- Gino & Michele

[toc] | [prev] | [next] | [standalone]

#15763

On 2012-01-11, daniele.g <daniele@father.nostromo.wy> wrote:
> 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?

No.

A macro is a good choice if you can write a single thing which expands to
something suitable on each of your target systems.  If you can't, you should
write a function for each system to provide the functionality.

The problem is that the conditional compilation doesn't do anything to solve
your actual *problem*, which is that if you don't spawn threads, the code
won't work.  You need to rethink that part of the design...

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#15764

Seebs <usenet-nospam@seebs.net> writes:

> On 2012-01-11, daniele.g <daniele@father.nostromo.wy> wrote:
>> 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?
>
> A macro is a good choice if you can write a single thing which expands to
> something suitable on each of your target systems.  If you can't, you should
> write a function for each system to provide the functionality.

I would say, instead, that a function (possibly marked "inline")
is a good choice in any case, and that a macro is a second choice
if a function cannot work.
-- 
"Large amounts of money tend to quench any scruples I might be having."
  -- Stephan Wilms

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web