[libgomp] MEMMODEL_* constants and OMP_STACKSIZE: a few questions/proposals
Kévin PETIT
kevin.petit@arm.com
Mon Jul 15 16:32:00 GMT 2013
Ping.
Hi,
I’ve recently started to work on libgomp with the goal of proposing
a new way of handling queues of tasks based on the work done by a
PhD student.
While working on libgomp’s code I noticed two things that puzzled me:
- The code uses gcc’s atomic builtins but doesn’t use the
__ATOMIC_* constants to select the desired memory model for the
operation. Instead it uses the MEMMODEL_* constants defined in
libgomp.h. Is there a good reason for that? I’d be very tempted to
(possibly) “fix” it with the attached patch.
- When using the OMP_STACKSIZE environment variable to select
the stack size of the threads, it only applies to the threads created
by pthread_create and has no effect on the main thread of the process.
This behaviour looks compliant with version 3.1 of the spec:
“OMP_STACKSIZE sets the stacksize-var ICV that specifies the size of
the stack for threads created by the OpenMP implementation”
but I was wondering if it was the best thing to do? I discovered this
when playing with the UTS benchmark of the BOTS benchmark suite which
can require quite big stacks for some input datasets. It uses
OMP_STACKSIZE to set its requirements but that doesn’t prevent a task
with stack requirements bigger than the default size to be scheduled
on the main thread of the process, leading the application to crash
because of a stack overflow.
Should the application be setting itself the size of its main thread’s
stack? Shouldn’t something be done in the compiler/runtime to handle
this? That wouldn’t be not compliant with the spec and much more
intuitive to the programmer: “I can expect that every thread will have
OMP_STACKSIZE worth of stack”.
I should hopefully write again soon with some more useful patches and
proposals. In the meantime, thank you for your answers.
Regards,
Kévin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Don-t-redefine-an-equivalent-to-the-__ATOMIC_-consta.txt
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20130715/0376b3e9/attachment.txt>
More information about the Gcc
mailing list