concurrent tasks should be executed by different OS threads

[nelsc]

That's the intention, but we probably don't say it adequately.

[BlaineGarst]

The main concern is establishing what can and can't be done in a parallel section, such as in one of the counted loops. Can malloc/free be called, can setjjmp/longjmp be called, can _Thread_local variables be consulted, can tss_t variables be used without races. There is clearly compiler/runtime magic going on to make things compute in parallel, but some of that magic bleeds through. The goal seems to be that C11 standard threads will be used, by magic, to do computation concurrently, and that anything legal in a non-parallel context is legal in the parallel section. If so, then the correlation between "OS Thread" and that which thrd_create returns has to be made.

Another way to ask the question is whether thrd_current() is well-defined in a parallel section, i.e. can be used to distinguish concurrent executions of the parallel section.

Given that 7.26.5.1 simply says "thrd_create function creates a new thread..." I think the simplest proposed resolution to this is to
a) just delete "OS" from the phrase "OS Thread" in section 5
b) clean up Section 3.
3.4 "execution agent" should replaced by "thread" where its used to define what "cplex_set_num_threads" does. Sheesh.
3.1, 3.2, 3.3 should all fold into one definition of "thread"
3.5 "task" is woefully redefined to be unlike any other "task" I've seen in OSs, and is wrong. As it stands, it would seem to characterize completely independent threads as tasks simply because they didn't interact.

The definition of concurrent and parallel programs is somewhat bogus since, well, it is C11 and atomics does apply, and so just because the synchronization among worker threads and calling thread is hidden doesn't mean it doesn't exist. Simply saying that the counted loop compound statements (blocks) are executed on compiler/runtime worker threads is the truth - that they, internally become units-of-work in some fashion and may be called "tasks" for that runtime doesn't mean its worthy enough to merit its own definition. There are no operations on "tasks", so its unnecessary conceptual overhead.
C has always been a what-you-see-is-what-you-get language and introducing poorly defined specialized terms doesn't help.

[jeffhammond]

As a potential user, I would like it if we could leverage C11 threads here, because that would make it possible to reason about the behavior of _Thread_local, etc. in a straightforward manner.

I do not think we should refer to OS threads at all, since C11 should be sufficient and there's no need to refer to operating system features in a programming language specification. If C11 threads are inadequate to specify the implementation details, then there's something wrong with how C11 threads are specified that should be fixed.

Building CPLEX features on C11 threads would have the added benefit of compelling implementers to support C11 threads at some point in the future. I am unaware of a single production implementation of C11 threads...

[phalpern]

I am willing to take on the non-trivial task of updating the definitions and usage of "thread" and "task" in the WP.

Tasks that run concurrently within a program should be assumed to run on separate C threads, and the C thrd facilities should be available for accessing _Thread_local storage, thread ID, etc.

The term, "task" is a term of art in the parallelism world and must stay, but is not adequately defined in the current WP. A task is not a thread, but a thread can run a task. Blaine points out that the current definition of a task could apply to completely independent threads. That is not necessarily a bad thing, but I think we do need to make it clear that a task might or might not run independently on other tasks, depending on how the task is created in the program. This will take a little work, but I think it is doable in time for the WG14 meeting.

[phalpern]

Proposed resolution is attached: CPLEX-Issue-1.pdf