“阻塞”与“等待”的区别

在并发编程中,"阻塞"和"等待"的含义确实有些相似,但在异步编程的上下文中,它们有着不同的含义。

在操作系统中,线程是最小的执行单元。当我们说一个操作是"阻塞"的,我们的意思是这个操作会停止线程的执行,直到某个条件得到满足。例如,在传统的同步I/O中,一个读操作会阻塞线程,直到数据可用为止。在阻塞期间,线程不能做任何其他的事情,它只是停在那里,等待读操作完成。

然而,在异步编程中,我们使用了一种不同的模型。当我们说一个操作是"等待"的,我们的意思是这个操作会让出线程的控制权,直到某个条件得到满足。例如,在异步I/O中,一个读操作(如ReadAsync)会立即返回一个任务,代表这个操作的完成情况。在等待这个任务时,线程可以去做其他的事情。这就是所谓的"非阻塞"行为。

在Unity的主线程中调用ReadAsync时,主线程就是调用线程。当我们在主线程中使用await关键字等待ReadAsync的结果时,主线程会立即返回,可以去做其他的事情,而不是被阻塞,等待数据可用。

所以,尽管ReadAsync在没有数据可读的时候会"等待",但这并不意味着它会"阻塞"调用线程。相反,它会立即返回一个表示操作完成情况的任务,这让调用线程有机会去做其他的事情。当数据可用时,ReadAsync的任务会完成,然后调用线程可以继续从那里执行。这就是异步编程的优势,它可以提高程序的响应性和效率。

参考:GPT4

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容