Re: [Gomp-discuss] Start of an OpenMP Implementation Spec

[Jacob Weismann Poulsen]

Hi Ross,

I have just read you proposal with great pleasure! I have a few
initial questions/comments to the runtime-model that you describe.

1) Just to confirm my understanding: You say that the _OMP_MasterFunction
is supposed to create or wake up existing slave threads. If I 
understand this correct you plan to maintain a pool of threads who 
may either spin or do some real work as requested by a par_region. 
The size of this list may grow and shrink during execution and 
the _OMP_MasterFunction will when called have to ensure that the list
have the desired size (by lookup in some data structure that we maintain
within the library) embarking on the real stuff. Once they finish 
doing the real stuff the _OMP_MasterFunction will tell all non-master 
threads to spin again.
An _OMP_init() will (among other things) setup this list/pool whose 
size is determined by environment variables or by counting processors
on the system. An _OMP_resize() will allow the _OMP_MasterFunction to
resize this pool.

2) I am not sure that I understand your intentions with the
_OMP_Params array completely. I assume that your sample_region_i 
functions eventually will be used in a pthread creation but maybe I got
it wrong (maybe you don't assume the pthread API). If not, sample_region_i 
must be on the form

        void *sample_region_i (void *arg)

and you will consequently have to pass your arguments via a pointer to a 
structure. Moreover I would suspect that we would need other information 
(e.g. thread_id) accessible from within each thread too.  That is, I assume
that we would need something like:

struct _thread_args {
    int thread_id;
        ...
        void *func_args;
};

where func_args would be a struct tailored to the region
in question, e.g. your sample2 would be something like:

struct _sample2_args {
        float *a;
        float *b;
        float *c;
        long n;
};

Am I totally off the track here ??? Please give us further details
about your intentions with _OMP_Params.

3) Just of curiosity: Why have you chosen to put the par_cond test
in _OMP_MasterFunction. Why not check in the caller function and avoid 
the overhead of calling _OMP_MasterFunction ??? I am probably missing 
a good point.

Keep up the good work,

Cheers, Jacob

-- 
<address@hidden>
Fingerprint: 9315 DC43 D2E4 4F70 3AA8  F8F0 9DA0 B765 F5C8 7D26