對于線程資源共用問題，實際上也沒有一個最完美的解決方案，沒有最適合的，只有根據情況來分析，找合適的方法，我最近在做角色之間的位置信息交換，已經實現了一部分了。感覺很爽
其中角色的位置在變，還要同時通知給所有其他的玩家，這其實應該是件頭痛的問題
我前面的文章已經說明，我吧地形劃分為一個個的tile，那么角色的信息只發送給身邊9個tile里面其他的玩家，剛如果換了，tile，那么還要通知最后離開的三個tile里面的玩家，該角色已經不在可視范圍之內了。這樣的信息。那么就存tile里面同時要增加也要刪除也要讀取并且（發送）的處理
這些信息是具有高并發量的。如果處理的不好，角色是會很卡的。
我想了很久終于用一個巧妙的方法解決了這個難題，應該會比較高效的。
我定義了個這樣的結構：
//某個線程的臨時資源，在鎖定一個資源的時候，可以根據需要，需要處理的數據拷貝到這個線程本地資源中去
//然后解鎖再去處理這些數據，所占用的時間僅僅迭代和copy的時間，處理過程可以根據需要來決定是否應該同步（如果不同步，就不用占用臨界鎖了)
//可以從一定程度上，減少線程對資源的占有時間，減少線程碰撞機會,充分提高系統性能
//這種處理手法來源于java里面的ThreadLocal，里面的集合就是用來做為線程本地資源的。
//進程里面開辟的線程數量不會太多，本地資源應該有很多分類
typedef struct _LocalThreadResource
{
DWORD ThreadId; //當前線程的id
//copy-process處理，這個特點都是從頭往尾順序加數據,不存在插入數據的情況，訪問也是從頭到尾，用vector最合適了
//并且處理完了也不用清理（清理也要花時間），下次使用，復制的時候再從頭到尾以iterator的方式copy
vector<LPSESSION> mNotifingUsers;//本次線程需要通知給周圍的角色id
DWORD mNotifingUsersLen; //保留上面集合的有效數據的集合的長度
//根據需要添加更多的資源
} LocalThreadResource;
這個結構通過ThreadIdThreadId 關聯到線程中去，當前的線程ID可以用GetThreadID來獲取，
對于讀取數據和處理的過程大致如下：
void TileInfo::Insert(LPSESSION playerid)
{
mlock.lock();
players.insert(playerid);
mlock.unlock();
}
void TileInfo::Remove(LPSESSION playerid)
{
mlock.lock();
players.erase(playerid);
mlock.unlock();
}
void TileInfo::SendMsgToPlayersInTile(BasePack *pack,int len, char *from)
{
//得到當前的線程id
DWORD currentThreadId = GetCurrentThreadId();
//根據線程id得到當前線程的本地資源
LocalThreadResource *localresource = gServer->LocalThreadResourceMap[currentThreadId];
localresource->mNotifingUsers.resize(10);
//加鎖
mlock.lock();
//把需要處理的數據復制到線程本地資源，也許你對copy耿耿于懷，后來我思考了一下，其實不存在重新創建，而且數據量不大，簡單的復制，速度是很快的，最大的好處，就是鎖不用鎖那么久，這點損失無妨。
copy(players.begin(), players.end(), localresource->mNotifingUsers.begin());
//記錄需要處理的數據的長度
localresource->mNotifingUsersLen = players.size();
//解鎖
mlock.unlock();
int i = 0;
std::vector<LPSESSION>::iterator itor = localresource->mNotifingUsers.begin();
//處理需要處理的線程本地數據
for(; i < localresource->mNotifingUsersLen && itor!= localresource->mNotifingUsers.end(); itor++, i ++)
{
LPSESSION lpSession = (LPSESSION) *itor;
gServer->SendInUdp(lpSession, (char *)pack, len, from);
}
}
//把讀取和處理過程完全分開，讀數據和處理異步（減少鎖占用的時間），讀和寫通過臨界區來互斥。
我最終采納了這個方案