A ‘ringbuffer’ application is Devices might be ‘idle', Devices might be ‘busy’, Avoid ‘busy waiting’, ‘blocking’ while idle, ‘run’ queues and ‘wait’ queues, Kernel waitqueues, Kernel’s support routines, Use of Linux wait queues. | A ‘ringbuffer’ application Introduction to process ‘blocking’ and the Linux kernel’s support for ‘sleeping’ and ‘waking’ Devices might be ‘idle’ • With our previous device-driver examples (., dram, cmosram), the data to be read was already there, just waiting to be input • But with certain other character devices, such as a keyboard, a program may want to input its data before any new data has actually been entered by a user • In such cases we prefer to wait until data arrives rather than to abandon reading Devices might be ‘busy’ • Sometimes an application wants to ‘write’ some data to a character device, such as a printer, but the device temporarily is not able to accept more data, being still busy with processing previously written data • Again, in such situations we prefer to just wait until the device becomes ready for us to send it more data rather than to give up We could do ‘busy waiting’ • It is possible for a device-driver to ‘poll’ a status-bit continuously until data is ready, (or until a device is no longer “too busy”): do { status = inb( 0x64 ); } while ( ( status & READY ) == 0 ); • Such a technique is called ‘busy waiting’ • But it could waste a lot of valuable CPU time before any benefit was realized! Avoid ‘busy waiting’ • In a multitasking system we would want to avoid having any processes use the ‘busy waiting’ strategy whenever possible, as it ‘stalls’ any progress by other tasks – it’s a system-performance ‘bottleneck’! • So modern operating systems support an alternative strategy, which allows those tasks that could proceed to do .
