gomp-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gomp-discuss] Organization of libgomp source code


From: Lars Segerlund
Subject: Re: [Gomp-discuss] Organization of libgomp source code
Date: Tue, 18 Feb 2003 12:48:17 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9


Linux threads has a separate stack for each thread, so you can pass argument so them, ( they are supported in glic ).

We can keep a local context on the stack, no worries, simple, but let's forget about it now.

 How about the directories ? Shall I make a runtime, lib and testing ?
 and continue to create a changelog and some auto files ?


I am looking at code from the intel compiler, and looking for some papers on threaded code from a company called tera ... they have some solutions and have done a lot of work on these issues.

We have other threading problems such as the synchronisation and such .. also we should if possible make our binaries run without libgomp and threads, a fallback to nuthing. ( it's easy and might make life easier for a lot of people ).

 / regards, Lars

Steven Bosscher wrote:
Op di 18-02-2003, om 12:14 schreef Biagio Lucini:

On 18 Feb 2003, Steven Bosscher wrote:


It doesn't work right now because you need to set library properties
that we had not defined yet (e.g. these is no omp_num_threads variable
yet). Also the schedule environment variable isn't implemented yet. Also, reading the environment should somehow just be part of the library
initialization.

So, it was just an example of how it *could* be done.  It's quite easy
to actually make it work, though.


Thanks, Steven. As soon as I have some time (!!!) I'll try and modify it.
I think the strategy should be
a) define the OpenMP environment (you did it)
b) set our default (or is there any OpenMP spec for that?)
c) read the enviro & overwrite the default
d) pass the enviro structure to all OpenMP functions as required (then I
guess it must be declared as extern?)
e) overwrite it locally when a library function does it.


I was more thinking:
a) At startup (initialization), read the environment, and
   set the default if the environment variable is not set.
b) The omp_set_num_threads () (?) function can adjust the
   default at runtime.
c) Use the clause value for the OpenMP functions as required.
   If the clause is absent, the compiler sets the num_threads
   value to, say, -1, and the functions use the default.

So, the defaults are global variables, and there is a local value for
each parallel region, which is either the default, or the number from
the num_threads clause.

Greetz
Steven




_______________________________________________
Gomp-discuss mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/gomp-discuss






reply via email to

[Prev in Thread] Current Thread [Next in Thread]