fwrite 内部是否调用任何锁？
在Solaris 中，当我将dbx 连接到正在运行的堆栈之一时，我发现对fwrite 的调用导致了__lll_lock_wait()？
什么情况下会发生这种情况？ fwrite 是否在内部尝试获取锁？
In solaris when I attached dbx to one of the running stacks, I found the call to fwrite leading to __lll_lock_wait()?
In what scenario will this happen? Does fwrite internally tries to acquire a lock?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我查看的标准（C99 和 POSIX）没有提及有关
fwrite的锁定或解锁 IO。在我的 Linux 系统上，
man页面中对锁定的提及不太准确：实际上，有一个
fwrite_unlocked函数。 POSIX 中的标准解锁函数只有getc_unlocked()、getchar_unlocked()、putc_unlocked()和putchar_unlocked()>。我的解释是，可能 man(3) 集中的所有缓冲 IO 都被锁定，并且您只有很少的标准化接口来执行解锁 IO。
这些东西在线程之间锁定确实是一件好事，否则当多个线程写入 stderr 时，您可能会得到完全混乱的输出，例如
the standards that I looked through (C99 and POSIX) do say nothing about locked or unlocked IO concerning
fwrite.On my linux system their is a not very precise mentioning of locking in the
manpage:and effectively, there is a
fwrite_unlockedfunction. Standard unlocked functions in POSIX are onlygetc_unlocked(),getchar_unlocked(),putc_unlocked(), andputchar_unlocked().My interpretation is that probably all buffered IO in the man(3) set is locked, and that you only have very few standardized interfaces to do unlocked IO.
That these things lock between threads is really a good thing since otherwise you could have completely messy output when several threads write to
stderr, e.g.