-
-
Notifications
You must be signed in to change notification settings - Fork 410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible violation of the pthread_create
interface?
#4324
Comments
Considered relevant during sync: https://stackoverflow.com/questions/9116951/what-is-the-meaning-of-restrict-in-pthread-create |
I think I was convinced over the duration of the sync call that this is indeed a spec violation (but I may still be under-informed on the issue, so I could be wrong). That is, I was convinced that some future version of The violation seems to be that our first arg and final arg to One way to avoid this would be to not embed the |
I'm not convinced this is an issue. We should discuss together at some point @jemc. I agree it is a violation of the quoted posix spec but I'm not sure that matters, what matters is whether that spec is implemented by our target platforms. |
Joe and I discussed at sync today. We both agree this could be an issue. I'm more worried that someone fixing this issue is likely to introduce bugs than clang and other compilers will start to follow this portion of the spec. I'm fine with someone fixing the issue herein so long as there is a test plan to make sure no bugs are introduced with the change to address the spec violation. |
So, I'm exploring the runtime codebase and make an assumption below about the behavior of
restrict
with respect to threads so I am probably wrong but I believe I found a violation of thepthread_create
interface in the pony runtime:In scheduler.c
The runtime calls
ponyint_thread_create
with a pointer to a scheduler's tid and a pointer the whole scheduler,Note that
run_thread
accessessched->cpu
⇒(*sched).cpu
⇒(*(scheduler_t*) arg).cpu
which is an access to*(scheduler_t*) arg
before any synchronization.ponyint_thread_create
callspthread_create
with those arguments,The POSIX docs say
pthread_create
is declared:In addition the POSIX docs for
pthread_create
do not specify whether or not the new thread begins executing beforepthread_create
itself returns, so I assume it does.The behavior of
restrict
is complicated, and I am only referencing a draft of C11, but if the assumption above extends to the definition ofrestrict
, the beginning ofstart_routine
(on the new thread) occurs "During [the] execution of [the block associated with the restrict qualified pointerarg
]"start_routine
accesses the lvalue*(scheduler_t*) arg
which has&(*(scheduler_t*) arg)
based onarg
,*(scheduler_t*) arg
is modified by the write to*thread
bypthread_create
, but this is an access to the value of*(scheduler_t*) arg
which is not based onarg
and thus the behavior is undefined.So, did I do a mistake in my reasoning, is my assumption wrong, or is this actually undefined?
I doubt anything but a sanitizer would behave contrary to expectations even so, but It would be wrong regardless.
The text was updated successfully, but these errors were encountered: