業務環境是這樣的：
1.因為存在一些共有資源，部分業務邏輯，要加鎖，防止其他幾個執行緒改變測驗環境（物理上的測驗環境），造成測驗結果失敗
所以要求在暫停時/詢問用戶是否重做時，必須把共有資源讓出來（離開Lock），讓其他幾個執行緒來執行 ，等用戶點擊繼續/重做時，再準備進入Lock，而這些類似的行為 很多時候往往是嵌套的
2.這種多執行緒任務，不一定是同一時間開始，前后有有可能時間差很多，而其中一些步驟會改變測驗環境，所以要求前面先開始的業務，能夠等待后加入的業務，執行到同一步驟后在繼續（執行到同一步驟時，測驗環境會變成一致的）；
3.因為性能上的考慮，這些等待后加入的業務執行到一個階段時，所有進入該階段的業務，要統一執行
我遇到的問題，大概就是這個，希望大佬先行者，能幫忙給一些經驗之談，謝謝
uj5u.com熱心網友回復：
“要求在暫停時/詢問用戶是否重做時，必須把共有資源讓出來”--這個有時候不一定，可能要求原地阻塞----希望大佬們給點意見或者建議，謝謝
uj5u.com熱心網友回復：
因為我們不知道你的實際需求。所以只能談談控制策略
1.策略一：不管以前的，以前的讓他自然做。只管后續的
2.策略二：讓以前停止，重新做。
所以我們其實不不是加鎖，我們是采用背景關系和生存期去控制
如果說你現在用netcore以上版本就能理解，理解不了也沒關系，我們用netcore以上版本的東西去講，你理解了可以自己實作類似的東西
public class AppContext
{
private readonly IServiceProvider _provider;
private IServiceScope _scope;
public AppContext(IServiceProvider provider)
{
_provider = provider;
創建新的公共物件生存期();
}
public 公共環境物件 創建新的公共物件生存期()
{
_scope = _provider.CreateScope();
return Session;
}
public 公共環境物件 公共環境物件 => _scope.ServiceProvider.GetService<公共環境物件>();
}
我們先貼一個這樣的代碼
services.AddSingleton<AppContext>();
services.AddScoped<公共環境物件>();
也就是當你說的某個執行緒“呼叫創建新的公共物件生存期”方法時候，他會重新new一次公共環境物件。
這樣后續新增的任務就會按照新的背景關系環境去執行。
而舊的任務，如果要沿用舊的，你舊不用管。如果說你要讓他使用新的那么在實作IServiceScope這東西時候加一個dispose處理，讓他在釋放前去做一些動作，比如通知舊任務更新背景關系，比如通知舊任務直接結束，比如通知舊任務進行事務回撤并重新按新背景關系重做
紅字標識的只是策略，我們不做具體討論，因為他是你們更具專案特性而具體選擇的策略，這些不是技術了
uj5u.com熱心網友回復：
ps：與博客園大神們不同，他們的core特指asp.net core而我們core指的是通用應用框架，目前微軟這套東西明顯區別與以前的語言級框架，他其實就是通用應用級別框架（比如你這里的應用---系統背景關系和應用級別生存期控制，很明顯這些都是應用架構級別，而不是傳統的語法功能級別的東西）。包括最近那波大神說了“net6了，maui”，但是你能很明顯的get到的資訊是，“MaUI”就是典型的在這套通用應用框架體系下出來的東西
uj5u.com熱心網友回復：
2.這種多執行緒任務，不一定是同一時間開始，前后有有可能時間差很多，而其中一些步驟會改變測驗環境，所以要求前面先開始的業務，能夠等待后加入的業務，執行到同一步驟后在繼續（執行到同一步驟時，測驗環境會變成一致的）前面我們談了一些新架構下的控制，然后在去談談你這個老的設計的，這個玩意傳統上叫“執行緒同步”，也就是讓某些執行緒等待特定事件完成。這個不是lock，這個是同步信號量控制（很多人喜歡把這類放執行緒里談，但實際上他是IO操作，而非執行緒操作，也就是等待一個IO完成動作，而不是等待一個執行緒執行動作）
uj5u.com熱心網友回復：
感謝您的回答
，謝謝，謝謝大佬1.策略一：不管以前的，以前的讓他自然做。只管后續的
2.策略二：讓以前停止，重新做。
策略一，因為共有的資源是硬體，硬體搭建了一個測驗環境 ，而這個測驗環境，會隨著業務的推進，發生改變，比如溫度（室溫~零下幾百攝氏度），體積，一些硬體的位置等其他條件；但有時這些后加入的業務流程需要和前面的流程一起來處理某個同一步驟（中途不加，可不用處理，這樣做是為了時間效率，因為測驗時間很長，一般可能要幾十個小時），所以這個業務流程，不管是后加還是先加，都必須要考慮和處理
策略二：現在的想法是這個樣子的，
讓先開始的業務流程等待后面中途加塞的；有一個死回圈，不停的輪詢這些個業務流程（和硬體相關的共用資源），讓業務排在最前面的先執行，直到所有執行緒的流程相同，再處理
當遇到暫停/或者可重做的例外時，跳出子業務后，在鎖外面等待用戶回應
不知道這樣是否可行，希望大佬幫忙給點意見
備注：軟體是上位機；Winform
uj5u.com熱心網友回復：
你給我們一個具體實際應用場景口語化表達（別用啥執行緒啊，鎖啊這類表示）也就是系分的“測驗用例”“故事卡片”這樣的東西，我們在結合你的具體故事和用例在去討論，現在這種術語話表達我們很難知道你到底困在那里
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/269616.html
標籤：C#