看門狗一般分爲硬件看門狗和軟件看門狗，主要用來解決程序CPU異常，程序跑飛掛死等問題，提高系統的可靠性。
看門狗分硬件看門狗和軟件看門狗。硬件看門狗是利用一個定時器電路，其定時輸出連接到電路的復位端，程序在一定時間範圍內對定時器清零(俗稱“喂狗”)，因此程序正常工作時，定時器總不能溢出，也就不能產生復位信號。如果程序出現故障，不在定時週期內復位看門狗，就使得看門狗定時器溢出產生復位信號並重啓系統。軟件看門狗原理上一樣，只是將硬件電路上的定時器用處理器的內部定時器代替，這樣可以簡化硬件電路設計，但在可靠性方面不如硬件定時器，比如系統內部定時器自身發生故障就無法檢測到。當然也有通過雙定時器相互監視，這不僅加大系統開銷，也不能解決全部問題，比如中斷系統故障導致定時器中斷失效。
看門狗本身不是用來解決系統出現的問題，在調試過程中發現的故障應該要查改設計本身的錯誤。加入看門狗目的是對一些程序潛在錯誤和惡劣環境干擾等因素導致系統死機而在無人干預情況下自動恢復系統正常工作狀態。看門狗也不能完全避免故障造成的損失，畢竟從發現故障到系統復位恢復正常這段時間內怠工。同時一些系統也需要復位前保護現場數據，重啓後恢復現場數據，這可能也需要一筆軟硬件的開銷。
在單任務系統中，程序一般都是一個大循環，沒有任務調度，只要在初始化階段開啓看門狗，然後在大循環程序內部合適的地方進行看門狗定時器清零即可，比較容易實現。但是在多任務系統中，由於任務的調度，如下圖（a）所示，只要有一個任務正常工作並定期喂狗，看門狗定時器就不會溢出。除非所有任務都鼓掌，才能使得看門狗定時器溢出而復位。如圖b。
而我們往往要求，只要有一個任務故障，系統就要求復位。或者選擇幾個關鍵的任務接受監視，只要有一個任務出故障就要求系統進行復位，如下圖a所示，相應邏輯如圖b
一般結合嵌入式操作系統，設置一個優先級級別最高的任務作爲監視器，以監視各個應用任務是否正常運行，該監視器即爲軟件看門狗，該任務對其他任務都設定一個計時器，每個被監視的任務在設定的時間內對軟件看門狗中相應的定時器定時清零，即喂軟狗，在其他任務都正常工作的情況下，軟件看門狗對內置的硬件看門狗定時器週期性清零，即喂狗。
在多任務系統中通過創建一個監視任務TaskMonitor，它的優先級高於被監視的任務羣Task1、Task2...Taskn。TaskMonitor在Task1~Taskn正常工作情況下，一定時間內對硬件看門狗定時器清零。如果被監視任務羣有一個Task_x出現故障，TaskMonitor就不對看門狗定時器清零，也就達到被監視任務出現故障時系統自動重啓的目的。另外任務TaskMonitor自身出故障時，也不能及時對看門狗定時器清零，看門狗也能自動復位重啓。接下來需要解決一個問題是：監視任務如何有效監視被監視的任務羣。
在TaskMonitor中定義一組結構體來模擬看門狗定時器組
typedef struct
{
UINT32 CurCnt, LastCnt;
BOOL RunState;
int taskID;
} STRUCT_WATCH_DOG;
該結構體包括被監視的任務號taskID，用來模擬“喂狗”的變量CurCnt、LastCnt(具體含義見下文)，看門狗狀態標誌RunState用來控制當前任務是否接受監視。
被監視的任務Task1~Taskn調用自定義函數CreateWatchDog(int taskid)來創建看門狗，被監視任務一段時間內要求“喂狗”，調用ResetWatchDog(int taskid)，這個“喂狗”動作實質就是對看門狗定時器結構體中的變量CurCnt加1操作。TaskMonitor大部分時間處於延時狀態，假設硬件看門狗定時是2秒，監視任務可以延時1.5秒，接着對創建的看門狗定時器組一一檢驗，延時前保存CurCnt的當前值到LastCnt，延時後比較CurCnt與LastCnt是否相等，都不相等系統纔是正常的。需要注意的是CurCnt和LastCnt數據字節數太小，而“喂狗”過於頻繁，可能出現CurCnt加1操作達到一個循環而與LastCnt相等。
如果有任意一組的CurCnt等於LastCnt，認爲對應接受監視的任務沒有“喂狗”動作，也就檢測到該任務出現故障需要重啓，這時候TaskMonitor不對硬件看門狗定時器清零，或者延時很長的時間，比如10秒，足以使得系統重啓。反之，系統正常，Task1~Taskn定期對TaskMonitor“喂狗”，TaskMonitor又定期對硬件看門狗“喂狗”，系統就得不到復位。還有一點，被監視任務可以通過調用PauseWatchDog(int taskid)來取消對應的看門狗，實際上就是對STRUCT_WATCH_DOG結構體中的RunState操作，該標誌體現看門狗有效與否。
這種方式可監視的最大任務數由STRUCT_WATCH_DOG結構數據的個數決定。程序中應該有一個變量記錄當前已創建的看門狗數，判斷被監視任務Task1~Taskn是否“喂狗”只需比較CurCnt與LastCnt的值n次。
圖3：系統復位邏輯圖
硬件看門狗監視TaskMonitor任務，TaskMonitor任務又監視其他的被監視任務Task1~Taskn，形成這樣一種鏈條。這種方式系統的故障圖表示如圖3所示。被監視任務Task1~Taskn及TaskMonitor都是或的關係，因此被監視的任一任務發生故障，硬件電路看門狗就能復位。爲實現多任務系統的看門狗監視功能額外增加了TaskMonitor任務，這個任務佔用執行時間多少也是一個重要問題。假設TaskMonitor任務一個監視週期延時1.5秒，此外需要執行保存當前計數值，判斷是否“喂狗”等語句，它的CPU佔用時間是很小的。用一個具體的試驗證實，使用50M工作頻率的CPU(S3C4510)，移植vxWorks操作系統，cache不使能條件下監視10個任務，每個監視週期佔用220~240微秒。可見該任務絕大多數時間都處於任務延時狀態。
被監視任務可能有獲取消息、等待一個信號量等的語句，往往這個消息、信號量的等待是無限期的等待。這就需要將這類語句作一些修改。比如在vxWorks中將一次無期限的獲取信號量操作。
semTake(semID, WAIT_FOREVER); // WAIT_FOREVER爲無限時間等待
分解爲
do
{
ResetWatchDog; // “喂狗”操作
}while(semTake(semID, sysClkRateGet( )) != OK); // 1s內的等待信號量操作
多次的時間範圍內的獲取信號量操作，這樣才能保證及時“喂狗”。
另外需要注意的是系統中是否有的任務優先級比TaskMonitor高並且長時間處於執行狀態，TaskMonitor長時間得不到調度，使得看門狗錯誤復位。良好的任務劃分，配置是不應該出現這種高優先級任務長期執行狀況的。