Suggestion on PThreads (passing argument, example3)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 43/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c
- Domain
- documentation
Research direction
Review the PThreads tutorial's “Passing Arguments to Threads” section and its “Example 3 - Thread Argument Passing (Incorrect)” code and output. Compare the displayed output with the stated lesson about shared variable t changing before a thread reads it; done means the example and explanation consistently illustrate that point.
Written by the indexing model from the issue text.
Description
As from the title, in PThreads tutorial, Passing Arguments to Threads, Example 3
Example 3 - Thread Argument Passing (Incorrect)
This example performs argument passing incorrectly. It passes the address of variable t, which is shared memory space and visible to all threads. As the loop iterates, the value of this memory location changes, possibly before the created threads can access it.
int rc;
long t;
for(t=0; t<NUM_THREADS; t++)
{
printf("Creating thread %ld\n", t);
rc = pthread_create(&threads[t], NULL, PrintHello, (void *) &t);
...
}
with output
Creating thread 0
Creating thread 1
...
Creating thread 7
Hello from thread 140737488348392
Hello from thread 140737488348392
...
Hello from thread 140737488348392
Hello from thread 140737488348392
It looks like the program prints the address of the variable t, which might be inconsistent with what we want to illustrate --- "the value of this memory location changes". Can we adjust this to something like the following?
void *PrintHello(void *threadid) {
long * tid;
tid = (long *)threadid;
printf("Hello World! It's me, thread #%ld!\n", *tid);
pthread_exit(NULL);
}
int main() {
pthread_t threads[NUM_THREADS];
int rc;
long t;
for (t = 0; t < NUM_THREADS; t++)
{
printf("In main: creating thread %ld\n", t);
/* Don't try to access memory location of t!
* It constantly changes as the loop goes!
* Possibly before the created threads can access it
*/
rc = pthread_create(&threads[t], NULL, PrintHello, (void *) &t);
if (rc)
{
printf("ERROR; return code from pthread_create() is %d\n", rc);
exit(-1);
}
}
/* Last thing that main() should do */
pthread_exit(NULL);
return 0;
}
So the output goes like
In main: creating thread 0
In main: creating thread 1
Hello World! It's me, thread #1!
In main: creating thread 2
Hello World! It's me, thread #2!
In main: creating thread 3
Hello World! It's me, thread #3!
In main: creating thread 4
Hello World! It's me, thread #4!
Hello World! It's me, thread #5!
which illustrates that the value t had been t++ed before the created thread read the location.
Thanks!
- Dominant language
- C
- Stars
- 258
- Forks
- 130
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from llnl/HPC-Tutorials
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
llnl/HPC-Tutorials#12 ·
All issues in llnl/HPC-Tutorials
Similar issues
-
severity: low
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
luainkernel/lunatik#1853 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 Half a day Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 5 days
-
constants.h: M_PI / M_PI_2 fallbacks cause -Wambiguous-macro when H3 is compiled as a Clang moduleOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
area:backend bug launch:p2 scope:core
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Chelis-Lang/chelis#3494 ·
Maintainers usually reply within 1 day