Date: Thu, 09 Oct 2003 02:38:03 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: frank@exit.com Cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. Message-ID: <3F852C7B.81133DDE@mindspring.com> References: <200310081536.h98FaFa1087800@realtime.exit.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Frank Mayhar wrote: > The other thing is that the unlocked reads about which I assume Jeffrey > Hsu was speaking can only be used in very specific cases, where one has > control over both the write and the read. If you have to handle unmodified > third-party modules, you have no choice but to do locking, for the reason > you indicate. On the other hand, you can indeed make such a rule as you > describe: For this global datum, we always either write or read it in a > single operation, we never do a write/read/modify/write. Hey, if it's > your kernel, you can make the rules you want to make! But it's better > to not allow third-party modules to use those global data. I'm pretty sure that Jeffrey is aware of read-modify-write issues with atomic vs. idempotent multi-instruction operations, since he generally knows what he's doing. 8-). Probably the most interesting cases, from his perspective in the network stack, are queue insertions and removals for singly linked queues, where the insertion OR removal can be done atomically without taking locks (but not both, except on fully MESI coherent systems without speculative execution). FreeBSD's use of queue structures is sometimes overkill, and the macro order of operations as they are currently defined prevent non-locking operations, even where they would be safe, if the order of operation were reversed (e.g. for a simple singly linked tail queue). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F852C7B.81133DDE>