多线程应用程序的策略

发布于 2024-08-12 14:19:46 字数 585 浏览 3 评论 0原文

我可能会继承一个有点复杂的多线程应用程序,该应用程序当前有几个具有 2+k loc 的文件、从各处访问的大量全局变量以及我认为非常臭的其他做法。

在开始使用当前模式添加新功能之前,我想尝试看看是否可以使应用程序的基本架构变得更好。这是一个简短的描述:

  • 应用程序在内存中具有数据列表,listA,listB
  • 应用程序具有数据的本地副本(用于离线功能)dataFileA,dataFileB
  • 应用程序具有线程tA1,tB1,它们将脏数据从客户端更新到服务器
  • 线程tA2,tB2更新从服务器到客户端的脏数据
  • 线程 tA3、tB3 将内存列表中的脏数据更新到本地文件

我对应该研究哪些不同的模式、策略、编程实践等有点麻烦,以便掌握做出最佳决策的知识关于这一点。

以下是我为自己制定的一些目标:

  1. 保持应用程序尽可能稳定
  2. 让 Generic Intern 可以轻松添加新功能(每个新的 EditRecordX.cs 中不得有 50 行样板代码)
  3. 降低复杂性

感谢您的帮助关键词或其他可以帮助我完成这个项目的技巧。

I might inherit a somewhat complex multithreaded application, which currently has several files with 2+k loc, lots of global variables accessed from everywhere and other practices that I would consider quite smelly.

Before I start adding new features with the current patterns, I'd like to try and see if I can make the basic architecture of the application better. Here's a short description :

  • App has in memory lists of data, listA, listB
  • App has local copy of the data (for offline functionality) dataFileA, dataFileB
  • App has threads tA1, tB1 which update dirty data from client to server
  • Threads tA2, tB2 update dirty data from server to client
  • Threads tA3, tB3 update dirty data from in memory lists to local files

I'm kinda trouble on what different patterns, strategies, programming practices etc I should look into in order to have the knowledge to make the best decisions on this.

Here's some goals I've invented for myself:

  1. Keep the app as stable as possible
  2. Make it easy for Generic Intern to add new features (big no-no to 50 lines of boilerplate code in each new EditRecordX.cs )
  3. Reduce complexity

Thanks for any keywords or other tips which could help me on this project.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

_失温 2024-08-19 14:19:46

对于 Quibblesome 的出色建议,我还可以补充一点,使用不可变对象通常是减少线程问题的风险。 (不可变对象,如 .NET 和 Java 中的字符串,一旦创建就无法修改。)

To Quibblesome's excellent suggestions, I might also add that using immutable objects is often an effective way to reduce the risk of threading problems. (Immutable objects, like strings in .NET and Java, cannot be modified once they are created.)

绿光 2024-08-19 14:19:46

我建议另一个目标是删除/减少全局状态并尽可能频繁地将信息保留在堆栈上,以减少竞争条件和奇怪的线程问题的可能性。

也许值得一看的是,您是否可以将 tA2、tB2、tA3 和 tB3 合并到同一线程中以杀死一些线程。如果这不可能,请考虑将它们放在外观(一个涉及在 UI 和与服务器通信的服务之间移动数据请求的线程)后面。这样一来,“面向用户”的代码只需处理一个客户端,而不是两个客户端。 (我不把备份算作客户端,因为这听起来像是一个单向过程)。

如果线程(UI 和 Facade)等待彼此完成其请求,那么这应该可以防止“拉动更新”与“推送更新”同时发生。

I'd suggest another goal would be to remove/reduce global state and keep information on the stack as often as possible to reduce the possibility of race conditions and weird threading issues.

Perhaps it might be worth seeing if you can incorporate tA2, tB2, tA3 and tB3 into the same threads to kill a few. If that isn't possible consider putting them behind a facade (a thread that concerns itself with moving data requests between the UI and the service that is talking to the server). This is so the "user facing" code only has to deal with one client as opposed to two. (I don't count the backup as a client as this sounds like a one-way process).

If the threads (UI and facade) wait for one another to finish their requests then this should prevent a "pull update" happening at the same time as a "push update".

亢潮 2024-08-19 14:19:46

一般来说,要进行此类更改,您需要查看 Martin Fowler 的 重构:改进现有代码的设计(其中大部分位于重构网站)以及重构模式。您还可能会发现有效使用旧代码对于支持安全更改很有用。除了在多线程环境中更容易处理更简单的代码之外,这些都对多线程没有多大帮助。

For making these kind of changes in general you will want to look at Martin Fowler's Refactoring: Improving the Design of Existing Code (much of which is on the refactoring website) and also Refactoring to Patterns. You also might find Working Effectively with Legacy Code useful in supporting safe changes. None of this is as much help specifically with multithreading, except in that simpler code is easier to handle in a multithreading environment.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文