Operating System-Thread(5)彈出式線程&&使單線程代碼多線程化會產生那些問題

本文主要內容

彈出式線程（Pop-up threads)

使單線程代碼多線程化會產生那些問題

一、彈出式線程（Pop-up threads)

以在一個http到達之后一個Service的處理為例子來介紹彈出式線程。

上面的例子中傳統(tǒng)的做法有可能是在Service中有一個線程一直在等待request的到達，等request到達后這個線程會開始檢查請求最后在進行處理。當這個線程在處理request的時候，后面來的request會被block，一直到線程處理完當前request為止。如下圖所示。

彈出式線程的處理方法：當有新的請求到達時，馬上創(chuàng)建一個線程去處理這個請求（彈出pop-up thread).

彈出式線程的優(yōu)勢：

線程是全新的，沒有歷史，創(chuàng)建很快

request沒有被block，請求到達到開始處理之間的延遲非常小

在使用彈出式線程時需要額外考慮一下，這個線程是應該運行在那里比較好。用戶空間還是內核空間。將線程放在內核相對會比較容易，但是因為在內核，如果該線程出問題，危害性將比用戶空間的線程大。

?二、使單線程代碼多線程化

一些既有的代碼都是基于單線程的，如果將其修改為支持多線程會產生那些后果呢，下面簡單一一做一下分析。

2.1 多線程共享變量

圖示：

n在t1、t2之間共享：

T1調用Check程序檢查自己的狀態(tài)，得的n=1這個狀態(tài)

在T1得到狀態(tài)使用n之前cpu被調度給了T2。

T2調用Check程序檢查自己的狀態(tài)，得的n=2這個狀態(tài)

CPU再次被調度到T2，這個時候n已經等于2了，產生了錯誤的結果。

上面的問題是可以被優(yōu)化的，讓T1和T2取消這個對N的共享，讓其各自維護自己的狀態(tài)碼N1，和N2即可避免上述問題。

2.2 重復進入

類似于上面的共享問題，一個Library提供一個功能，在一個線程進入該Library后沒有返回之前另外一個線程又進入了，會產生什么問題呢。

比如這個Library在請求沒有返回之前將數據放入buffer，那么這個時候另外一個線程進入這個Library會將原有buffer的數據重置，從而對第一個線程的執(zhí)行造成不可預估的后果。

這種問題可以讓Library提供一個標志位，當這個Library處于調用狀態(tài)時，設置標志位，這樣后續(xù)的請求將會被block，從而解決問題，但是這會降低程序的并行執(zhí)行能力。

2.3 信號（中斷處理）

比如一個鍵盤key down信號，應該有那個線程處理，要不要pop-up一個新的線程

有多個線程時，如何一個線程修改了信號，要不要同時通知其他線程

同一個信號，不同線程的處理可能完全不一樣，比如ctrl+c，有些線程用于粘貼，有些用于終止程序。

信號的處理在單線程程序中就已經很復雜了，多線程是復雜度加倍。

2.4 堆管理

在很多系統(tǒng)中，當一個進程的堆棧異常時（stackoverflow），內核自動為這個進程分配堆棧，當一個進程有多個線程時，勢必會有多個堆棧，當內核沒有完全了解所有堆棧，有可能某些堆棧發(fā)生堆棧異常時，內核并不知道，無法為其自動分配堆棧。

2.5 all

如果在沒有經過大量分析和設計的前提下將多線程引入一個現(xiàn)有的單線程系統(tǒng)會產生很多不可預知的錯誤，絕不是一個簡單的引入多線程機制那么簡單，要從Library等各個方面進行分析和設計，確保在線程安全的情況下再引入多線程。后期引入多線程的成本要比剛開始設計就包含多線程要高很多。

總結

以上是生活随笔為你收集整理的Operating System-Thread(5)弹出式线程使单线程代码多线程化会产生那些有关问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。