九十年代经典国内电影:udelay, msleep

udelay(unsigned long usecs);
mdelay(unsigned long msecs);

前者用软件循环指定的微妙数，后者调用前者达到延迟毫秒级。udelay 函数只能用于获取较短的时间延迟，因为loops_per_second值的精度只有8位，所以，当计算更长的延迟时会积累出相当大的误差。尽管最大能允 许的延迟将近1秒(因为更长的延迟就要溢出)，推荐的 udelay 函数的参数的最大值是取1000微秒(1毫秒)。延迟大于 11 毫秒时可以使用函数 mdelay。
要特别注意的是 udelay 是个忙等待函数（所以 mdelay 也是），在延迟的时间段内无法运行其他的任务，因此要十分小心，尤其是 mdelay，除非别无他法，要尽量避免使用。 
mdelay 在 Linux 2.0 中并不存在，头文件 sysdep.h 弥补了这一缺陷。

关于 usleep sleep 主要的差距在精确程度上，不过网友有关于这个方面的精辟论断：
同样我觉得select也是比较好的定时机制，不过大家可以看igmp-proxy的源代码。主函数里面用setitimer和select同时定时是一个相当好的想法。

另外，我发现，大多驱动里用到的是udelay，应用层用的是msleep。

在时序相求比较严格时，可以用udelay。

以下摘自别处：

在 linux 2.4 下：
          1、支持 usleep,nanosleep,select
          2、select 的 精确度为 10毫秒。在10毫秒以上很精确
          3、usleep， nanosleep 很不精确

同样，通过其它测试程序能得出如下结论：
          sleep 可以在多线程中使用，只阻塞本线程，不影响所属进程中的其它线程

usleep()有有很大的问题

1. 在一些平台下不是线程安全，如HP-UX以及Linux
2. usleep()会影响信号
3. 在很多平台，如HP-UX以及某些Linux下，当参数的值必须小于1 * 1000 * 1000也就是1秒，否则该函数会报错，并且立即返回。
4. 大部分平台的帮助文档已经明确说了，该函数是已经被舍弃的函数。

还好，POSIX规范中有一个很好用的函数，nanosleep()，该函数没有usleep()的这些缺点，它的精度是纳秒级。在Solaris的多线程环境下编译器会自动把usleep()连接成nanosleep()。

Linux下短延时推荐使用select函数.