Is fprintf thread safe on OS X? If so, where is this documented?
The POSIX threads specification (AKA Pthreads), which OS X conforms to, requires that stdio functions are thread safe. It also provides the flockfile and funlockfile functions to ensure that other threads can't interleave I/O on a FILE * whilst it is locked.
See http://pubs.opengroup.org/onlinepubs/007908799/xsh/threads.html, specifically under the section titled "Thread-safety".
This was a good question, although similar questions have been asked here many times. I was interested in the OSX aspect because I trying to get up to speed on that system myself. (maybe you should add the OSX tag)
I THINK fprintf() is thread safe on OSX. My first reason for this is that the Darwin people were going in that direction as evidenced by their choice to drop the old-school global 'errno' in favor of the function errno(). For documentation, just follow '/usr/include/errno.h'. Without that, none of the libc stuff would be thread safe. Yet the use of the errno() function doesn't prove anything about fprintf(). It's just a start. I'm sure everyone knows of at least one situation where Apple didn't carry through with a good idea.
Another reason I believe in the 'thread-safety' of fprintf() is the source code, which is supposed to be 'the real thing', at least until 10.6 when Apple closed (part / all) of OSX. Scan that code for "MT-Safe" and you will see a CLAIM that the non-locale version of 'vfprintf()' is thread safe. Again, that doesn't prove anything. Yet it is a form of documentation, which you wanted.
My final reason to believe fprintf() is thread-safe was a test case. This doesn't prove much of anything either. Maybe it proves the buffer space is thread safe. OK, it was an excuse to write a little program for fun. Actually, I didn't write it. I found a skeleton online, and modified it. The "FLUSH_BUFFER" definition allows you to more clearly see what's happening. If that macro isn't defined, you get 'sort-of' buffer test (same text without some line-terminators). I couldn't figure out a way to arrange a more meaningful collision of the threads.
I'll guess you might be writng to multiple files. Writing to a single file is probably a better test. The attached program isn't a definitive test. Although it could be extended, I'm not sure any program could really be definitive. Bottom line: maybe you should just MUTEX your calls to fprintf().
// artificial test for thread safety of fprintf()
// define FLUSH_BUFFER to get a good picture of what's happening, un-def for a buffer test
// the 'pretty print' (FLUSH_BUFFER) output relies on a mono-spaced font
// a writeable file name on the command line will send output to that file
//
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define FLUSH_BUFFER
#define NTHREAD 5
#define ITERATIONS 3
const char DOTS[] = ". . . . . . . . . . . . . . . . . . . . . . . . . . . . ";
FILE *outFile;
void *PrintHello(void *threadid) {
long tid;
tid = (long)threadid;
for (int i=1; i<=ITERATIONS; i++) {
long delay = (NTHREAD-tid) * 100000 + (ITERATIONS-i+1) * 10000;
#ifdef FLUSH_BUFFER
fprintf(outFile, "%*sStart thread %d iteration %d\n", (tid+1)*4, " ", tid, i);
usleep(delay);
fprintf(outFile, "%*sFinish thread %d iteration %d %*.*sw/delay %d\n",
(tid+1)*4, " ", tid, i, (NTHREAD-tid+1)*4, (NTHREAD-tid+1)*4, DOTS, delay);
#else
fprintf(outFile, "Start thread %d iteration %d ", tid, i);
usleep(delay);
fprintf(outFile, "Finish thread %d iteration %d w/delay %d\n", tid, i, delay);
#endif
}
pthread_exit(NULL);
}
int main (int argc, char *argv[]) {
pthread_t threads[NTHREAD];
char errStr[100];
int rc;
long t;
if(argc > 1) {
if(! (outFile = fopen(argv[1], "w"))) {
perror(argv[1]);
exit(1);
}
} else
outFile = stdout;
for(t=0; t<NTHREAD; t++) {
fprintf(outFile, "In main: creating thread %ld\n", t);
if(rc = pthread_create(&threads[t], NULL, PrintHello, (void *)t)) {
sprintf(errStr, "ERROR; pthread_create() returned %d", rc);
perror(errStr);
exit(2);
}
}
pthread_exit(NULL);
}
Related
I am using VS 2022 Preview to write a C++ console application. I wish to detect a keyboard hit and have my interrupt handler function called. I want the key press detected quickly in case main is in a long loop and therefore not using kbhit().
I found signal() but the debugger stops when the Control-C is detected. Maybe it is a peculiarity of the IDE. Is there a function or system call that I should use?
Edit: I am vaguely aware of threads. Could I spawn a thread that just watches kbd and then have it raise(?) an interrupt when a key is pressed?
I was able to do it by adding a thread. On the target I will have real interrupts to trigger my ISR but this is close enough for algorithm development. It seemed that terminating the thread was more trouble than it was worth so I rationalized that I am simulating an embedded system that does not need fancy shutdowns.
I decided to just accept one character at a time in the phony ISR then I can buffer them and wait and process the whole string when I see a CR, a simple minded command line processor.
// Scheduler.cpp : This file contains the 'main' function. Program execution begins and ends there.
//
#include <Windows.h>
#include <iostream>
#include <thread>
#include <conio.h>
void phonyISR(int tbd)
{
char c;
while (1)
{
std::cout << "\nphonyISR() waiting for kbd input:";
c = _getch();
std::cout << "\nGot >" << c << "<";
}
}
int main(int argc, char* argv[])
{
int tbd;
std::thread t = std::thread(phonyISR, tbd);
// Main thread doing its stuff
int i = 0;
while (1)
{
Sleep(2000);
std::cout << "\nMain: " << i++;
}
return 0;
}
My Code
#include<stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/wait.h>
int main()
{
char * arg_list[3];
arg_list[0] = "ls";
arg_list[1] = "-l";
arg_list[2] = 0;
char *arg_list2[3];
arg_list2[0] = " ps";
arg_list2[1] = "-ef";
arg_list2[2] = 0;
for(int i=0;i<5;i++){ // loop will run n times (n=5)
if(fork() == 0) {
if (i == 0){
execvp("ls", arg_list);
}else if(i==1){
execvp("ps" , arg_list2);
}else if(i>1){
printf("[son] pid %d from [parent] pid %d\n",getpid(),getppid());
exit(0);
}
}
}
for(int i=0;i<5;i++) // loop will run n times (n=5)
wait(NULL);
}
ME trying to modify it
#include<stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/wait.h>
int main()
{
for(int i=0;i<5;i++){ // loop will run n times (n=5)
if(fork() == 0) {
printf("[son] pid %d from [parent] pid %d\n",getpid(),getppid());
execlp(argv[i],argv[i],argv[i+1],(char*)NULL);
exit(0);
}
}
for(int i=0;i<5;i++) // loop will run n times (n=5)
wait(NULL);
}
-- NEED GUIDANCE AND UNDERSTANDING
I am trying to make my own tiny little shell program. When I run my first code works fine, runs all commands on the command line. But I cannot know and define all commands the user might enter. So i am trying to get a base code which could run any commands single or multiple entered by user. I tried using execlp where it does not compile saying argv is not defined which is true as i don't want to specifically define it.
I am trying to make my own tiny little shell program. When I run my first code works fine, runs all commands on the command line. But I cannot know and define all commands the user might enter.
For sure.... A shell program purpose is basically:
Read user input
Execute user input
Return result of execution.
There's nothing in your code that read user input....
So i am trying to get a base code which could run any commands single or multiple entered by user.
So read user input ;-)
I tried using execlp where it does not compile saying argv is not defined which is true as i don't want to specifically define it.
For sure ... but how would GCC guessed that `argv[]̀ must be automaticallty filled with user input ?
There's nothing automatic when coding in C language. You have to manage this manually.
Also, note that argc, argv et envp are usually reserved for main() function:
main(int argc, char **argv, char **envp)
So you may use something else to build your command array.
In pseudo code, what you must implement is:
quit=0
while (quit = 0) {
command_to_run = read_user_input();
if (command_to_run == "exit") {
quit = 1;
} else {
execute(command_to_run);
}
}
Some advices:
Try to use more functions. For example, implement a fork_and_run(char **cmd) function to fork and then execute command provided by the user. Il will make your code more readable and easy to maintain.
Read carefully manpages: everything you should know (like, for example, the fact that array provided to execvp() must be NULL-terminated) is written in it.
Your debugging messages should be printed to stderr. The result of the command run must be printed to stdin, so use fprintf() instead of printf() to write to the correct stream.
I would use a #define debug(x) fprintf(stderr, x) or something similar for debugging output so that you can easily disable later ;-)
Does ThreadFunc() gets called two times here? sometimes I notice a single call and sometimes none at all.
#include <windows.h>
#include <stdio.h>
DWORD WINAPI ThreadFunc(LPVOID);
int main()
{
HANDLE hThread;
DWORD threadld;
hThread = CreateThread(NULL, 0, ThreadFunc, 0, 0, &threadld );
printf("Thread is running\n");
}
DWORD WINAPI ThreadFunc(LPVOID p)
{
printf("In ThreadFunc\n");
return 0;
}
Output 1
Thread is running
In ThreadFunc
In ThreadFunc
Press any key to continue . . .
Output 2
Thread is running
In ThreadFunc
Press any key to continue . . .
Output 3
Thread is running
Press any key to continue . . .
In order to call CRT functions, such as printf you should use _beginthread or _beginthreadex instead of CreateThread.
Anyway, the program may end before the thread has the opportunity to output anything.
A little addition: use WaitForSingleObject inside main() to give your thread finish a job.
No, ThreadFunc should never get called twice. In any case, I believe your code snippet is incomplete - could you post the full code snippet where you are seeing this problem?
I'm trying to learn how to program parallel algorithms in C using POSIX threads. My environment is a Mac OS X 10.5.5 with gcc 4.
Compiling:
gcc -Wall -D_REENTRANT -lpthread source.c -o test.o
So, my problem is, if I compile this in a Ubuntu 9.04 box, it runs smoothly in thread order, on Mac looks like mutexes doesn't work and the threads don't wait to get the shared information.
Mac:
#1
#0
#2
#5
#3
#4
ubuntu
#0
#1
#2
#3
#4
#5
Any ideas?
Follow below the source code:
#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#define NUM_THREADS 6
pthread_mutex_t mutexsum;
pthread_t threads[NUM_THREADS];
long Sum;
void *SumThreads(void *threadid){
int tmp;
int i,x[10],y[10];
// Para cada x e y do vetor, jogamos o valor de i, só para meio didáticos
for (i=0; i<10 ; i++){
x[i] = i;
y[i] = i;
}
tmp = Sum;
for (i=0; i<10 ; i++){
tmp += (x[i] * y[i]);
}
pthread_mutex_lock (&mutexsum);
Sum += tmp;
printf("Im thread #%ld sum until now is: %ld\n",threadid,Sum);
pthread_mutex_unlock (&mutexsum);
return 0;
}
int main(int argc, char *argv[]){
int i;
Sum = 0;
pthread_mutex_init(&mutexsum, NULL);
for(i=0; i<NUM_THREADS; i++){
pthread_create(&threads[i], NULL, SumThreads, (void *)i);
}
pthread_exit(NULL);
}
There is nothing on your code that will make your threads running in ANY order. If in Ubuntu is running on some order, it might be because you are just lucky. Try running 1000 times in Ubuntu and see if you get the same results over and over again.
The thing is, that you can't control the way the scheduler will make your threads access the processor(s). So, when you iterate through the for loop is creating your threads, you can't assume that the first call to pthread_create will get to run first, or will get to lock the mutex you are creating first. It's up to the scheduler which it at the OS level, and you can't control it, unless you write your own kernel :-).
If you want a serial behavior why would you run your code in separate threads in the first place? If it is just for experimentation, then one solution I can think of using pthread_signal to wake a specific thread up and make it running... Then the woken up thread can wake up the second one and so on so forth.
Hope it helps.
To my recollection, the variable you have protected isn't actually being shared amongst the processes. It exists in its own context inside each of the threads. So, it's really just a matter of when each thread gets scheduled that determines what will print.
I don't think one simple mutex will allow you to guarantee correctness, if correctness is defined as printing 0, 1, 2, 3 ...
what your code is doing is creating multiple execution contexts, using the code in your sum function as its execution code. the variable you are protecting, unless declared as static, will be unique to each call of that function.
in the end, it is coincidence that you are getting one system to print out correctly, because you have no logical method of blocking threads until it is their proper turn.
I don't do pthreads in C or any other language (but I do thread programming on high-performace computers) so this 'answer' might be useless to you;
What in your code requires the threads to pass the mutex in thread id order ? I see that the threads are created in id order, but what requires them to execute in that order /
If you do require your threads to execute in id order, why ? It seems a bit as if you are creating threads, then serialising them. To what end ?
When I program in threads and worry about execution order, I often try creating a very large number of threads and seeing what happens to the execution order.
As I say, ignore this if my lack of understanding of C and pthreads is too poor.
I have an application that is multithreaded - one thread is responsible for collecting the dead children with wait(), anther thread spawns them with fork upon request.
I found out that on one platform with 2.4 kernel and LinuxThread wait always fails with ECHILD. I've found out that problem might be in non-POSIX compliant implementation of LinuxThreads on 2.4 kernel and the following discussion suggests that there is no way how this could be solved.
Still I'd like to be sure that nobody knows about any solution. Even patch for the kernel would be acceptable.
When I think about the application design I don't think it could be possible to do both fork() and wait() in a single thread (or only with enormous effort)
It seems to me that this (obviously bogus) behavior is features of LinuxThreads implementation.
There really seems to be only two ways out - either switch to NPTL (requires kernel 2.6) or avoid such multi-threaded fork/wait model (this was my solution to the problem and tough it made the architecture a bit more complicated and complex it still was manageable to do in a single day)
Following example is the bare bone example of the bogus situation that fails on LinuxThreads.
#include <pthread.h>
#include <sys/wait.h>
#include <unistd.h>
#include <errno.h>
void * wait_for_child(void *arg)
{
int s;
pid_t ret;
ret = wait(&s);
if (ret == -1 && errno == ECHILD) perror("Bogus LinuxThreads encountered");
return NULL;
}
int main(int argc, char ** argv)
{
pid_t pid = fork();
if (pid == -1) return 1;
// child waits and then dies
if (pid == 0)
{
sleep(3);
return 0;
}
pthread_t wt;
pthread_create(&wt, NULL, wait_for_child, NULL);
pthread_join(wt, NULL);
return 0;
}
If you're starting to think about kernel patches, then it's time to think about upgrades. 2.4 is very long in the tooth.