spin

linux环境：ubuntu16.04 交叉编译工具 arm-cortexa9-linux-gnueabi (一)下载opencv2.4.9源码 下载地址: opencv (二)配置编译环境 安装cmake cmake-qt-gui (三)配置编译选项 打开cmake-gui 配置编译选项 Compilers选项中的C选择*-gcc C++选择*-g++,要找到交叉编译工具链所在位置。 find program include 编译工具的库函数(lib)的位置 点Advanced 接下来是终极配置！！不按照以下配置必然会报错！！ 去掉BUILD_OPENEXR 去掉BUILD_opencv_ocl 去掉WITH_1394 去掉WITH_CUDA 去掉WITH_GSTREAMER(没见到) 去掉WITH_GTK(没见到) 去掉WITH_LIBV4L(后边有v4l这个没用不要选)(没见到) 去掉WITH_OPENCL 去掉WITH_OPENEXR 去掉WITH_TIFF 在cmake-gui中去掉BUILD_opencv_apps这一项的钩钩！！！ 勾上BUILD_JASPER 勾上BUILD_JPEG 勾上BUILD_PNG 勾上BUILD_ZLIB CMAKE_C_FLAGS 设置为-O3 -fPIC CMAKE_CXX_FLAGS 设置为-O3 -fPIC CMAKE

　　等待队列在内核中很有用途，尤其用在中断处理、进程同步及定时。 　　等待队列实现了在事件上的条件等待：希望等待特定事件的进程把自己放进合适的等待队列，并放弃控制权。因为，等待队列表示一组睡眠的进程，当某一条件变为真时，由内核唤醒他们。 1.每个等待队列都有一个等待队列头(wait queue head)，等待队列头是一个类型为wait_queue_head_t的数据结构： struct __wait_queue_head { spinlock_t lock; struct list_head task_list; }; typedef struct __wait_queue_head wait_queue_head_t; 　　因为等待队列是由中断处理程序和主要内核函数修改的，因此必须对其双向链表进行保护以免对其进行同时访问，因为同时访问会导致不可预测的后果。同步是通过等待队列头中的lock自旋锁达到的。task_list字段是等待进程链表的头。 2.等待队列链表中的元素类型为wait_queue_t: struct __wait_queue { unsigned int flags; #define WQ_FLAG_EXCLUSIVE 0x01 void *private; wait_queue_func_t func; struct list_head task_list; }

转自：http://blog.csdn.net/wh_19910525/article/details/11536279 自旋锁的初衷：在短期间内进行 轻量级的锁定 。一个被争用的自旋锁使得请求它的线程在等待锁重新可用的期间进行自旋( 特别浪费处理器时间 )，所以自旋锁不应该被持有时间过长。如果需要长时间锁定的话, 最好使用信号量。 单处理器的自旋锁： 首先，自旋锁的目的如果在系统不支持内核抢占时，自旋锁的实现也是空的，因为单核只有一个线程在执行，不会有内核抢占，从而资源也不会被其他线程访问到。 其次，支持内核抢占，由于自旋锁是禁止抢占内核的，所以不会有其他的进程因为等待锁而自旋. 最后，只有在多cpu下，其他的cpu因为等待该cpu释放锁，而处于自旋状态，不停轮询锁的状态。所以这样的话，如果一旦自旋锁内代码执行时间较长，等待该锁的cpu会耗费大量资源，也是不同于信号量和互斥锁的地方。 简单来说，自旋锁在内核中主要用来防止多处理器中并发访问临界区，防止内核抢占造成的竞争。 自旋锁内睡眠禁止睡眠问题： 如果自旋锁锁住以后进入睡眠，而此时又不能进行处理器抢占(锁住会disable prempt)，其他进程无法获得cpu，这样也不能唤醒睡眠的自旋锁，因此不相应任何操作。 自旋锁为什么广泛用于内核： 自旋锁是一种轻量级的互斥锁，可以更高效的对互斥资源进行保护

在前面文章描述spin_lock的时候, 要求spin_lock/unlock中间的代码不能有主动放弃cpu, 进入睡眠的函数。 (如sleep, schedule()等) 下面提一个问题? Q: 那在spin_lock/unlock中间代码段执行时, 时间片到了怎么办? A: spin_lock和spin_unlock中间代码是原子上下文。 故时间片轮转到了， 也不会调度。。。 类似中断上下文, 软中断/task_let内(还是在中断上下文), 以及spin_lock保护的区域内, 都是原子上下文, 无法睡眠。 因为如果睡眠了.... 中断上下文就回不来了.... 对应的, 进程上下文可以睡眠, 调度, 故有些中断下半部使用工作队列, irq_thread等机制, 使下半部存在于进程上下文, 可以睡眠。 贴一个别人的描述: 内核的一个基本原则就是：在中断或者说原子上下文中，内核不能访问用户空间，而且内核是不能 睡眠的。也就是说在这种情况下，内核是不能调用有可能引起睡眠的任何函数。一般来讲原子上下文指的是在中断或软中断中，以及在持有自旋锁的时候。内核提供 了四个宏来判断是否处于这几种情况里： #define in_irq() (hardirq_count()) //在处理硬中断中 #define in_softirq() (softirq_count()) //在处理软中断中

被自旋锁保护的临界区代码执行时不能睡眠。单核处理器下，获取到锁的线程睡眠，若恰好此时CPU调度的另一个执行线程也需要获取这个锁，则会造成死锁；多核处理器下，若想获取锁的线程在同一个处理器下，同样会造成死锁，若位于另外的处理器，则会长时间占用CPU等待睡眠的线程释放锁，从而浪费CPU资源。 若中断服务程序也要获得锁，则被自旋锁保护的临界区代码执行时不能被其他中断打断。原因同上类似。 被自旋锁保护的临界区代码在执行时，内核不能被抢占，亦同上类似。由自旋锁代码本身处理 来源： CSDN 作者： DADA2ndTIAN 链接： https://blog.csdn.net/zsj1126/article/details/103825089