我有一个带有两个线程的 C 程序,其中一个线程几乎一直阻塞在等待用户输入的 fgets()
中。第二个线程可能需要打印到终端,而第一个线程在 fgets()
上被阻塞。
从我的测试来看,程序似乎在等待第一个线程上的 fgets()
返回,然后第二个线程可以打印。
当另一个线程在 fgets()
上被阻塞时,这是它工作的人还是我可以打印?
此实现在 eCos(嵌入式可配置操作系统)上运行。
线程锁定在 fgets()
上:
int my_getline (char** argv, int argvsize)
{
static char line[MAX_LINE];
char *p;
int argc;
fgets(line, MAX_LINE, stdin);
for (argc=0,p=line; (*line != '\0') && (argc < argvsize); p=NULL,argc++) {
p = strtok(p, " \t\n");
argv[argc] = p;
if (p == NULL) return argc;
}
argv[argc] = p;
return argc;
}
尝试打印的线程:
while(1){
unsigned char bufr[50];
read_until(bufr);
if (bufr[1] == (unsigned char)NMFL ){
cyg_mutex_lock(&scree_mtx);
printf("Memory half full!\n");
cyg_mutex_unlock(&scree_mtx);
continue;
}
cyg_mbox_put( mbx_serial_userH, bufr );
}
输出(我确定消息之前就在那里):
最佳答案
C 标准根本没有指定标准输入流和标准输出流之间的任何关联。特别是,它没有指定阻塞通过任何标准函数从标准输入读取的线程应该导致任何输出函数阻塞。
但是,该标准也没有相反的说法,即一个线程在 stdin
的输入输入上阻塞不得导致另一个线程在输出到 stdout
时阻塞。这是否会发生取决于 C 实现,也可能取决于与 stdin
和 stdout
关联的特定设备。
您似乎正在使用 Windows C 实现,其中 stdin
和 stdout
都连接到 CMD.EXE 窗口。 Windows 有很多特性,我倾向于猜测您观察到的阻塞就是其中之一。我不希望在 Linux 或 OSX 上出现相同的情况,但这并不意味着它是错误的。
关于c - fgets() 是否锁定 stdout 以防止 printf,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53732189/