最快同步
我有以下情况：
该程序有一个到套接字的读取器和写入器线程，这是一个外部应用程序。 读者和作者需要协调一致地工作。
写入器向套接字发送动态数量的消息 (x)，读取器需要从套接字读取响应。每个周期的消息数量超过 5 到 10k。消息的接收顺序与发送的顺序不同，并且消息具有清晰的布局，因此可以确定单个消息。
读者需要读取 x 消息并在 .x 消息之后执行一些处理。读取器执行读后处理后，写入器需要重新开始向套接字发送。
从您的 pov 最快的同步是什么？
- 使用以下命令向套接字发送特殊消息 书面消息的数量？ （即使套接字上没有 FIFO 保证）
- 使用经典锁定对象吗？
对具有写入消息数量的整数使用原子事务，并让写入者仅更新该整数一次？
我是否错过了任何其他快速同步机制？
I have the following scenario:
The program has a reader and a writer thread to a socket which is an external application.
The reader and writer need to work in coordinated cycles.
The writer sends a dynamic number of messages (x) to the socket and the reader needs to read the responses from the socket. The number of messages is over 5 to 10k per cycle. The messages are not received in the same order as sent and the message have a clear layout, so it is possible to determine single messages.
The reader needs to read x messages and perform then some processing after the . The writer needs to restart sending to the socket after the reader has performed the after-reading processing.
What is the fastest synchronisation from your pov?
- Sending a special message to the socket with the
number of written messages? (Even though there is no FIFO guarantee on the socket) - Work with the classical locking object?
Use atomic-transactions for integers with the number of written messages and let the writer update the integer only once?
Have I missed any other fast synchronizing mechanism?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除非您以每秒 100,000 次的速度执行此操作，否则哪种机制比另一种机制快微秒并不重要。只需使用最容易理解和/或最容易发挥作用的机制。然后只有在发现机制不够快时才考虑优化该机制。消息处理本身很可能会比同步多使用几个数量级的时间。
Unless you are doing this on the order of 100,000 times per second, it doesn't really matter which mechanism is microseconds faster than another. Just use whatever mechanism is the easiest to understand and/or get working. Then only consider optimizing the mechanism if it turns out to not be fast enough. More than likely the message processing itself will use several orders of magnitude more time than this synchronization.