fifo

疑问 两个线程分别有不同的调度策略，一个SCHED_FIFO，一个SCHED_OTHER，按照之前的理解，SCHED_FIFO实时线程一定会占用CPU一直运行，导致SCHED_OTHER的普通线程得不到CPU，事实是这样么？ 验证 写了一小段代码，一个是验证SCHED_FIFO的高优先级线程会不会抢占低优先级的线程，在不主动放弃的情况下一直运行，一个是测试普通优先级的线程会不会得到CPU时间； 1 #include <stdio.h> 2 #include <stdlib.h> 3 #include <unistd.h> 4 #define __USE_GNU 5 #include <pthread.h> 6 #include <sched.h> 7 8 long long a = 0; 9 long long b = 0; 10 11 int attach_cpu(int cpu_index) 12 { 13 int cpu_num = sysconf(_SC_NPROCESSORS_CONF); 14 if (cpu_index < 0 || cpu_index >= cpu_num) 15 { 16 printf("cpu index ERROR!\n"); 17 return -1; 18 } 19 20 cpu_set_t mask; 21 CPU_ZERO(&mask)

本人大二，这两年才刚接触单片机，这个暑假用MPU6050练习一下I2C通讯，结果I2C还好说，但在使用MPU6050时遇到很多问题，上网查有些问题也没有具体的原因和解决方案。于是有了一个在这里汇总记录一下我遇到的问题和解决办法的主意。要是能顺便帮到也被这些问题所困惑的各位就更好了。由于本文性质更偏向于总结、日记，文中含有一些个人吐槽。 那么接下来就直接进入主题。 I2C 在这里我不多提关于I2C的部分，只说一点。I2C的通讯以我目前了解有两种。一种是全程利用延迟，对SDA和SCL的输出和接收高低电平的时间进行控制以起到通讯作用。二是利用中断接收ACK信号以起到通讯作用。在实际操作中，发现第二种通讯会对DMP的初始化产生影响。 我不打算不多说6050的初始化。无论是哪种I2C，只要能通讯，MPU6050的初始化是肯定没问题的。建议各位如果不确定I2C写的是否正确，可以先读取MPU6050的器件地址，这只和AD0这个引脚的接法有关，接地就是0X68,接电源就是0X69，要是可以正常读取，那就ok。 这里说一下我觉得DMP的一下麻烦的地方。 一． mpu_set_sensors(INV_XYZ_GYRO|INV_XYZ_ACCEL); //设置所需要的传感器 这一步基本不会出错，只要I2C没问题，肯定是直接过的。 二． mpu_configure_fifo(INV_XYZ_GYRO |

I create a FIFO, and periodically open it in read-only and non-blockingly mode from a.py: os.mkfifo(cs_cmd_fifo_file, 0777) io = os.open(fifo, os.O_RDONLY | os.O_NONBLOCK) buffer = os.read(io, BUFFER_SIZE) From b.py, open the fifo for writing: out = open(fifo, 'w') out.write('sth') Then a.py will raise an error: buffer = os.read(io, BUFFER_SIZE) OSError: [Errno 11] Resource temporarily unavailable Anyone know what's wrong? According to the manpage of read(2) : EAGAIN or EWOULDBLOCK The file descriptor fd refers to a socket and has been marked nonblocking (O_NONBLOCK), and the read would block.

众所周知，FIFO中文译为命名管道，是PIPE的升级版。而PIPE是管道，系统提供的一种进程间通讯方式，FIFO与PIPE有以下方面不同： 1） FIFO需要先在文件系统创建（mkfifo），之后使用文件接口操作（open/close/read/write）；而PIPE不与文件系统相关联，创建PIPE后直接读写(pipe)，无需打开； 2） PIPE只能在父子关系的进程间使用，本质是通过fork复制了母进程空间从而扩展到另一个进程；而FIFO关联的各个进程间更为自由，不必由fork产生也可以使用。 但他们都是管道，本质上就是内核开辟的一块缓存区，虽然FIFO在文件系统有一个入口，但是它和文件有很大不同，具体体现在使用FIFO的文件接口的几个限制上： 1） 如果读进程以只读方式打开FIFO，若此时还没有写进程打开FIFO，则读进程会阻塞在open上，直到有进程以写方式打开FIFO文件； 2） 如果写进程以只写方式打开FIFO，若此时还没有读进程打开FIFO，则写进程会阻塞在open上，直到有进程以读方式打开FIFO文件； 3） 如果进程以读写方式打开FIFO，此时open将不再阻塞，但是如果此时没有写进程向管道内写数据，则读取将阻塞在read上，直到有进程写入数据为止。（需要注意的是如果之前有进程写入过数据，但是该进程在本进程open之前已经关闭FIFO，则相应的数据是读不到的）；

前文 中笔者介绍了管道，本文接着介绍命名管道。文中演示所用环境为 Ubuntu 18.04 desktop。 命名管道(named pipe)又被称为先进先出队列(FIFO)，是一种特殊的管道，存在于文件系统中。命名管道与管道非常类似，但是又有自身的显著特征： 命名管道可以用于任何两个进程间的通信，而不限于同源的两个进程。 命名管道作为一种特殊的文件存放在文件系统中，而不是像管道那样存放在内核中。当进程对命名管道的使用结束后，命名管道依然存在于文件系统中，除非对其进行删除操作，否则该命名管道不会自行消失。 和管道一样，命名管道也只能用于数据的单向传输，如果要用命名管道实现两个进程间数据的双向传输，建议使用两个单向的命名管道。 创建命名管道 在命令行上创建命名管道 可以通过命令行命令 mkfifo 或 mknod 创建命名管道： $ mkfifo /tmp/testp $ mknod /tmp/testp p 可以通过 ls 命令查看命名管道的文件属性： 输出中的第一个字符为 p，表示这个文件的类型为管道。最后的 | 符号是有 ls 命令的 -F 选项添加的，也表示这个一个管道。 在程序中创建命名管道 在程序中创建命名管道，可以使用 mkfifo 函数，其签名如下： #include <sys/types.h> #include <sys/stat.h> int mkfifo

Inside a BASH script we can have multiple processes running in background which intercommunicate using named pipes, FIFOs registered on the filesystem. An example of this could be: #!/bin/bash mkfifo FIFO # BG process 1 while :; do echo x; done & >FIFO # BG process 2 while :; do read; done & <FIFO exit I wonder if it's possible to do the same intercommunication between background processes of a script without using a FIFO on filesystem, maybe with some kind of file-descriptor redirection. Here's an example that runs two subprocesses implemented as functions of the same shell-script... One

转自： https://blog.csdn.net/lsn946803746/article/details/52515225 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/lsn946803746/article/details/52515225 BLSP(BAM Low-Speed Peripheral) ， 每一个BLSP含有两个QUP, 每一个QUP可以被配置为I2C， SPI, UART, UIM接口， BLSP是高通对于低速接口的一种管理方式。 i2c@f9923000 { /* BLSP-1 QUP-1 */ cell-index = <1>; compatible = "qcom,i2c-qup"; #address-cells = <1>; #size-cells = <0>; reg-names = "qup_phys_addr"; reg = <0xf9923000 0x1000>; interrupt-names = "qup_err_intr"; interrupts = <0 95 0>; qcom,i2c-bus-freq = <100000>; qcom,i2c-src-freq = <19200000>; qcom,sda-gpio =

I've made a FIFO using the mkfifo command,and created two processes to use the FIFO to communicate.But I've found that while the processes using the FIFO,I removed the FIFO,and the two processes can still even use the non-existed FIFO to send data,why? The object has been removed from the filesystem, but just as with all other files it will continue to exist until all open file descriptors on/from it are closed. 来源： https://stackoverflow.com/questions/36790279/why-two-processes-can-still-use-a-fifo-to-communicate-after-the-fifo-been-delete