關于ACE_Task::last_thread()
在ACE應用中，我們經常用ACE_Task類實現多線程處理。由于ACE_Svc_Handler從ACE_Task派生，當你寫的應用程序使用了Acceptor-Connector框架同時又直接使用ACE_Task,如線程池，這時你會使用到ACE_Task。
因為許多ACE_Task對應是動態分配的，所以，必須在不再需要時把它們正確地釋放掉,知道何時可以釋放對象，這一點非常重要。C++NPv2第189頁描述了當多線程涉及到的task對象在它們退出時，使用ACE_Task::thr_count()方法確定正確釋放它們的方法。
在C++NPv2文檔中描述的過程并不不安全，這里有一個用例可以說明這一點。原因如下：
ACE在調用ACE_Task::close()掛鉤(hook)函數前檢查線程計數。
線程鎖(task thread)使控制線程計數順序化，所以不能通過調用ACE_Task::close()達到控制線程數這一目的，這是因為關閉掛勾（close hook)方法會刪除task 對象。因此，多個線程檢查ACE_Task:: thr_count()的值都為0是可能存在的。
舉例來說吧，我們假設這里有兩個線程，A和B,這給都要退出。線程A從svc()方法中退出控制，同時，ACE開始線程記錄保護(record-keeping)。ACE獲得線程鎖并把活動線程數從2減為1,接著，ACE釋放線程鎖并調用task的close()掛鉤方法。其間，線程B也從svc()方法中退出。在線程A檢查ACE_Task::thr_count()之前，ACE已執行線程B的清楚操作可能導致task的線程計數器從1變為0.如果那樣，線程A和B都會看到線程計數器為0，并都試圖清理task對象。這一點肯定不是好事.......
發現并指出這一問題是一位長時間使用ACE的用戶,Howard Finer，經過一些迭代和試驗Howard找到一個解決這一問題的辦法，即額外的維護線程計數器，記住到底是哪一個線程真實的把線程計數器從1變為0，（上述例子中的線程B）。這就要求ACE_Task增加一個新的方法 ：
ACE_thread_t ACE_Task::last_thread (void) const
所以，在你的代碼實現ACE_Task::close()時需要包含如下的檢查
if (ACE_OS::thr_equal (ACE_Thread::self (),
?????????????????????? this->last_thread ()))
? {
??? // Do the cleanup here...
? }
這個方法可能會出現在ACE 5.5.2中。