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