大型并行应用中的线程锁定
我有一个关于大型应用程序中的并行化和线程锁定同步的稍微更普遍的问题。我正在开发一个具有大量对象类型和深层架构的应用程序，该应用程序还利用了大多数关键任务的并行化。目前，同步是通过系统每个对象内部的线程锁定管理来完成的。问题在于锁定范围仅与每个对象一样大，而对象属性正在通过许多不同的对象传递，其中属性正在失去同步保护。
线程管理、“同步上下文”等方面的最佳实践是什么？在大型应用中？似乎唯一万无一失的解决方案是使数据同步应用范围广泛，以便任何对象可以随时安全地使用数据，但这似乎违反了面向对象的编码概念。
如何最好地解决这个问题？
I have a slightly more general question about parallelisation and threadlocking synchronization in large applications. I am working on an application with a large number of object types with a deep architecture that also utilises parallelisation of most key tasks. At present synchronisation is done with thread locking management inside each object of the system. The problem is that the locking scope is only as large as each object, whereas the object attibutes are being passed through many different objects where the attributes are losing synchronisation protection.
What is best-practice on thread management, 'synchronization contexts' &c. in large applications? It seems the only foolproof solution is to make data synchronization application wide such that data can be consumed safely by any object at any time, but this seems to violate object oriented coding concepts.
How is this problem best managed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一种方法是将对象设置为只读；另一种方法是将对象设置为只读。只读对象不需要任何同步，因为当另一个线程写入它时，任何线程都不可能读取它（因为没有线程写入它）。对象生命周期问题可以使用无锁引用计数（使用原子计数器来保证线程安全）来处理。
当然，缺点是如果你真的想改变一个对象的状态你不能；您必须创建一个新对象，该新对象是旧对象的副本（除了更改的部分之外）。根据您的应用程序的用途，该开销可能是可接受的，也可能是不可接受的。
One approach is to make your objects read-only; a read-only object doesn't need any synchronization because there is no chance of any thread reading it while another thread writes to it (because no thread ever writes to it). Object lifetime issues can be handled using lock-free reference counting (using atomic-counters for thread safety).
Of course the down side is that if you actually want to change an object's state you can't; you have to create a new object that is a copy of the old object except for the changed part. Depending on what your application does, that overhead may or may not be acceptable.