在 Linux 字符驱动程序中使用正确的锁定
我正在编写一个简单的字符设备驱动程序。 （内核2.6.26） 多个并发读取器和作家们期待着。
我不确定哪种类型的锁最适合用于同步对内部结构的短期访问。
任何建议将不胜感激
I am writing a simple character device driver. (kernel 2.6.26)
Multiple concurrent reader & writers are expected.
I am not sure what type of lock is best used to synchronize a short access to internal structures.
Any advice will be most appreciated
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
与 http://www.kernel.org 进行比较/pub/linux/kernel/people/rusty/kernel-locking/c214.html 。以前存在互斥体时的旧文档，但由于互斥体是睡眠锁，因此它们计入用户上下文。
spinlock — spinlock_bh — mutex — semaphore
如果您的数据结构仅由执行由用户空间触发的函数访问，则所有锁原语都可供您使用。这取决于“短访问”有多短的直觉。
然后，RCU 作为第五种做事方式，尽管它本身并不是一种锁定原语。 （它与锁原语之一一起使用。）
Compare with http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html . An old document from before when mutexes existed, but given mutexes are a sleeping lock, they count towards user context.
spinlock — spinlock_bh — mutex — semaphore
If your data structures are only ever accessed by functions whose execution is triggered by userspace, all lock primitives are available to you. It depends on gut feeling of how short a "short access" is.
And then there is RCU as a fifth way of doing things, though it is somewhat not a locking primitive in its own right. (It is used together with one of the lock primitives.)
从
互斥体开始。一旦你让它工作起来，你就可以考虑重新设计锁定。Start with a
mutex. Once you've got it working you can think about reworking the locking.