I was going through following link to understand pthreads:
pthreads information
The pthread_join() function description is confusing me:
If the target thread is already terminated, but not yet detached, the subroutine returns immediately.
The target thread is automatically detached after all joined threads have been woken up.
Could not understand these 2 statements
Related
im currently implementing freertos on a efm32gg mcu.
i use a startup thread to initialize the project.
this thread disables context switch (TaskSuspendAll) during the project initialization where other modules create their threads, so the initialization is only interrupted by interrupts, not by other threads.
at the end of the project initialization, the startup thread enabled context switch (ResumeAll).
the current demo project adds 1 thread which would blink a led.
as soon as the startup thread enables critical sections, which leads to the portYield call at some point, the application jumps back to the main() (I dont know if through a reset or through a call to main).
but when i just use the startup thread and keep the project initialization function empty, then as desired, freertos keeps running the idle task..
does someone have an idea what the reason for such a behavior could be?
With regards to creating threads while the scheduler is suspended, see number list item 9 on the following page of the FAQ, which basically says not to do that. The reason being that creating a thread may result in a context switch being needed (if the thread has a priority above the thread that created it), but if the scheduler is suspended that can't happen: https://www.freertos.org/FAQHelp.html
If you want to have an initialisation thread that creates other threads, but you don't want the other threads to run yet, then I would recommend having the priority of the initialisation thread above that of any threads it creates - then the scheduler won't choose any other threads. At the end of initialisation you can lower the priority of the initialisation thread, or just delete it, whichever is most appropriate.
I suspect in your case the board is being reset somehow, so you need to find the source of that.
Can anyone help me??. I am trying to kill them, but, that will require a signal. So, I thought of using cancel.
Definitely pthread_cancel will not free the thread's stack, given that the canceled thread may continue to execute for some time, for example, executing cancellation handlers.
Thread resources are cleaned up after both pthread_detach were called on the thread and the thread has terminated (which is possible to occur in either order).
Here's the situation, I have a thread running that is partially controlled by code that I don't own. I started the thread so I have it's thread id but then I passed it off to some other code. I need to be able to tell if that other code has currently caused the thread to block from another thread that I am in control of. Is there are way to do this in pthreads? I think I'm looking for something equivalent to the getState() method in Java's Thread class (http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#getState() ).
--------------Edit-----------------
It's ok if the solution is platform dependent. I've already found a solution for linux using the /proc file system.
You could write wrappers for some of the pthreads functions, which would simply update some state information before/after calling the original functions. That would allow you to keep track of which threads are running, when they're acquiring or holding mutexes (and which ones), when they're waiting on which condition variables, and so on.
Of course, this only tells you when they're blocked on pthreads synchronization objects -- it won't tell you when they're blocking on something else.
Before you hand the thread off to some other code, set a flag protected by a mutex. When the thread returns from the code you don't control, clear the flag protected by the mutex. You can then check, from wherever you need to, whether the thread is in the code you don't control.
From outside the code, there is no distinction between blocked and not-blocked. If you literally checked the state of the thread, you would get nonsensical results.
For example, consider two library implementations.
A: We do all the work in the calling thread.
B: We dispatch a worker thread to do the work. The calling thread blocks until the worker is done.
In both cases A and B the code you don't control is equally making forward progress. Your 'getstate' idea would provide different results. So it's not what you want.
I have an attached server thread blocked on an accept() waiting for connections. Externally I try to terminate the thread by calling pthread_cancel(), followed by pthread_join(). Upon calling the join, my program terminates with a SIGABRT.
I am, more than likely going to the detach the thread, and make it select() with a timeout to check for connections, so I can then "signal" it to quit. So, I know this is a solution, but being the curious type, I was wondering why the first solution doesn't work.
I think you're getting the program termination SIGABRT because of the pthread_cancel() -- when the blocked thread gets the signal, it probably dies. The signal delivery doesn't happen until after the call to pthread_cancel() has returned, so it just looks like it occurs because of the join call.
To check and see if my thoughts are right, I would insert a while(1); loop after the pthread_cancel() to see if you still get the SIGABRT.
I'm working on a project and cannot find any documentation that verifies signal/thread behavior for the following case.
I need to ensure that signals generated in a thread will be delivered by the offending thread (namely, SIGSEGV). I've been told that POSIX doesn't ensure this behavior and that pthreads, for example, can generate signals in pthread 1 yet have the signal delivered in pthread 2. Therefore, I'm planning on using clone(2) to have finer control of signal/thread behavior, but still cannot find documentation in the man pages that ensures signals will be delivered by the offending thread.
Hardcore systems programmers: any documentation or insights would be very much appreciated!
The POSIX chapter on Signal Generation and Delivery states that:
At the time of generation, a
determination shall be made whether
the signal has been generated for the
process or for a specific thread
within the process. Signals which are
generated by some action attributable
to a particular thread, such as a
hardware fault, shall be generated for
the thread that caused the signal to
be generated. Signals that are
generated in association with a
process ID or process group ID or an
asynchronous event, such as terminal
activity, shall be generated for the
process.
A synchronous SIGSEGV caused by an incorrect memory access in a thread is clearly such a signal "...generated by some action attributable to a particular thread...", so they are guaranteed to be generated for the offending thread (which means handled or ignored by that thread, as appropriate).
I'm pretty sure this works, even if it isn't guaranteed. I base this observation on the fact that I used to work at a company where we routinely handled SIGSEGV in multithreaded programs and printed a stack trace to a log file (based on currently location). We did this on a variety of platforms--windows, linux, tru64 unix, aix, hpux, sunos ... and maybe one or two others that I can't recall. This (usually!) works because the location of SIGSEGV is still on the current stack (the signal handling mechanism just adds a few call frames over top of it).
It's only fair to mention that there's very little that you should do in a signal handler because there aren't many functions that are async signal safe. We ignored this and mostly got away with it, except if I recall on sunos (or aix) where we would get burned--the process would occasionally (and seemingly randomly) hard exit inside the signal handler.
I believe the recommended approach is to NOT handle SIGSEGV, and let the process exit with a core dump so you can analyze later in a debugger.