青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

Error

C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
  217 Posts :: 61 Stories :: 32 Comments :: 0 Trackbacks
先看下boost給的例子,我覺得有問題:

#include
<boost/atomic.hpp> class spinlock { private: typedef enum {Locked, Unlocked} LockState; boost::atomic<LockState> state_; public: spinlock() : state_(Unlocked) {} void lock() {
// 可能這里的boost::memory_order_acquire有原子操作的效果吧,偶不是很理解,不過我覺得這里應(yīng)該用cae操作才對 while (state_.exchange(Locked, boost::memory_order_acquire) == Locked) { /* busy-wait */ } } void unlock() {
// 這里都直接寫不做檢查了,更加難以理解 state_.store(Unlocked, boost::memory_order_release); } };

有可能是我不理解后面的內(nèi)存訪問參數(shù)的意義,給下我自己的實(shí)現(xiàn):
class CESpinLock : boost::noncopyable
{
private:
    typedef 
enum {emUnlocked = 0, emLocked} EM_LockState;

public:
    CESpinLock() : m_atomicState(emLocked)
    {
    }

public:
    
void lock()
    {
        EM_LockState state 
= emUnlocked;
        
while(false == m_atomicState.compare_exchange_strong(state, emLocked))
        {
            state 
= emUnlocked;
        }
    }

    
void unlock()
    {
        EM_LockState state 
= emLocked;
        
while(false == m_atomicState.compare_exchange_strong(state, emUnlocked))
        {
            state 
= emLocked;
        }
    }

private:
    boost::atomic
<EM_LockState> m_atomicState;
};


可以適當(dāng)?shù)脑趂alse里邊加一點(diǎn)sleep操作感覺。

還有一點(diǎn)就是不太激烈這里的cae操作分兩種 strong和weak

bool compare_exchange_weak(T & expected, T desired, memory_order success_order, memory_order failure_order)

Compare current value with expected, change it to desired if matches. Returns true if an exchange has been performed, and always writes the previous value back in expected. May fail spuriously, so must generally be retried in a loop.

bool compare_exchange_strong(T & expected, T desired, memory_order order)

Compare current value with expected, change it to desired if matches. Returns true if an exchange has been performed, and always writes the previous value back in expected

實(shí)在不理解 May fail spuriously, so must generally be retried in a loop.的意義,不過看了代碼,在win32的實(shí)現(xiàn)上,weak是調(diào)用了stong實(shí)現(xiàn)的。



 VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:49:07
atomic的 compare_exchange_weak
compare_exchange_weak
有啥區(qū)別

求解釋
vczh.Iskandar<vczh@163.com>  21:49:27
不是一樣嗎
御虛舟北(314969051)  21:49:40
改代碼中, ing
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:49:49
Windows上的實(shí)現(xiàn)是一樣的
May fail spuriously, so must generally be retried in a loop. 
這一句怎么理解呢
vczh.Iskandar<vczh@163.com>  21:50:07
compare_exchange_weak
compare_exchange_weak
質(zhì)量最大vczh粉(402740419)  21:50:14
compare_exchange_weak
compare_exchange_weak

VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:50:16
strong

compare_exchange_strong
還有一個問題
class spinlock {
private:
  typedef enum {Locked, Unlocked} LockState;
  boost::atomic<LockState> state_;

public:
  spinlock() : state_(Unlocked) {}

  void lock()
  {
    while (state_.exchange(Locked, boost::memory_order_acquire) == Locked) {
      /* busy-wait */
    }
  }
  void unlock()
  {
    state_.store(Unlocked, boost::memory_order_release);
  }
};

boost例子給的 spinloc
怎么是這樣實(shí)現(xiàn)的
都沒有用cae操作
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:51:20
unlock都直接用store了
vczh.Iskandar<vczh@163.com>  21:51:50
不用compare
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:51:59
 為啥
無法理解
vczh.Iskandar<vczh@163.com>  21:52:34
想要解釋好麻煩
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:52:40
還有在Windows上
boost::memory_order_acquire
這個參數(shù)也沒用
貌似
求V神解釋
還有strong和weak的區(qū)別
質(zhì)量最大vczh粉(402740419)  21:54:46
spinlock本來就不用compare啊
直接swap就行了
while (state_.swap(1) == 1);
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:56:24
你看假設(shè)現(xiàn)在是lock狀態(tài)
boost的實(shí)現(xiàn)是無條件吧lock換成unlock
如果是繼續(xù)lock 他還是lock
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:58:08
只要要避免 重入吧
lock之前檢查一下
御虛舟北(314969051)  22:00:03
小康你的書收到?jīng)]有
質(zhì)量最大vczh粉(402740419)  22:03:17
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  21:58:08
只要要避免 重入吧
lock之前檢查一下

你用錯了他不管你
就是這個意思
同一個線程lock兩次也會死鎖
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  22:05:05
原來是這樣

但是他lock的時候不檢查,也會導(dǎo)致兩個線程同時lock吧?
while (state_.exchange(Locked, boost::memory_order_acquire) == Locked) {
      /* busy-wait */
    }

質(zhì)量最大vczh粉(402740419)  22:05:18
不會啊
假設(shè)A進(jìn)程先來了,lock成功了
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  22:05:33
怎能理解,我理解和直接賦值是一樣
我再去看
質(zhì)量最大vczh粉(402740419)  22:05:40
這不是復(fù)制
是exchange
swap
另一個線程exchange就會收到Locked
那么另一個線程就會while循環(huán),直到原來線程給設(shè)置了Unlocked
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  22:06:47
Exchange current value with new_value, returning current value 

exchange是把新值寫入舊值返回么?  不是這樣么?
我有點(diǎn)理解了
質(zhì)量最大vczh粉(402740419)  22:07:46
對啊,新值寫入,舊值返回,原子的
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  22:07:59
就是說寫入也是寫入的lock, 不影響之前的lock
當(dāng)前線程拿到舊值檢查是不是lock狀態(tài),如果是就繼續(xù)嘗試直到不是
質(zhì)量最大vczh粉(402740419)  22:08:00
所以只會有一個線程返回Unlocked,另一個線程會收到之前線程設(shè)置的Locked
VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  22:08:11
 受教了
質(zhì)量最大vczh粉(402740419)  22:08:13

VCZH.粉絲數(shù)組[0]<errorcpp@qq.com>  22:08:20
我貼到博客上去 

posted on 2013-03-31 21:49 Enic 閱讀(3805) 評論(1)  編輯 收藏 引用 所屬分類: cpp 1x and boost

評論

# re: boost::atomic 實(shí)現(xiàn) spinlock 2013-03-31 23:52 Enic
老外是這么說的:

http://cbloomrants.blogspot.be/2011/07/07-14-11-compareexchangestrong-vs.html


07-14-11 - compare_exchange_strong vs compare_exchange_weak

The C++0x standard was revised a while ago to split compare_exchange (aka CAS) into two ops. A quick note on the difference :

bool compare_exchange_weak( T * ptr, T * old, T new );

bool compare_exchange_strong( T * ptr, T * old, T new );

(BTW in the standard "old" is actually a reference, which is a damn shitty thing to do because it makes it very non-transparent that "old" gets mutated by these functions, so I am showing it as a pointer).
both try to do :


atomically {
if ( *ptr == *old ) { *ptr = new; return true; }
else { *old = *ptr; return false; }
}

the difference is that compare_exchange_weak can also return false for spurious failure. (the original C++0x definition of CAS always allowed spurious failure; the new thing is the _strong version which doesn't).
If it returns due to spurious failure, then *old might be left untouched (and in fact, *ptr might be equal to *old but we failed anyway).

If spurious failure can only occur due to contention, then you can still gaurantee progress. In fact in the real world, I believe that LL-SC architectures cannot gaurantee progress, because you can get spurious failure if there is contention anywhere on the cache line, and you need that contention to be specifically on your atomic variable to gaurantee progress. (I guess if you are really worried about this, then you should ensure that atomic variables are padded so they get their own cache line, which is generally good practice for performance reasons anyway).

On "cache line lock" type architectures like x86, there is no such thing as spurious failure. compare_exchange just maps to "cmpxchg" instruction and you always get the swap that you want. (it can still fail of course, if the value was not equal to the old value, but it will reload old). (BTW it's likely that x86 will move away from this in the future, because it's very expensive for very high core counts)

compare_exchange_weak exists for LL-SC (load linked/store conditional) type architectures (Power, ARM, basically everything except x86), because on them compare_exchange_strong must be implemented as a loop, while compare_exchange_weak can be non-looping. For example :

On ARM, compare_exchange_weak is something like :

compare_exchange_weak:

ldrex // load with reservation
teq // test equality
strexeq // store if equal
and strexeq can fail for two reasons - either because they weren't equal, or because the reservation was lost (because someone else touched our cache line).
To implement compare_exchange_strong you need a loop :

compare_exchange_strong:

while ( ! compare_exchange_weak(ptr,old,new) ) { }

(note that you might be tempted to put a (*old = *ptr) inside the loop, but that's probably not a good idea, and not necessary, because compare_exchange_weak will eventually load *ptr into *old itself when it doesn't fail spuriously).
The funny bit is that when you use compare_exchange you often loop anyway. For example say I want to use compare_exchange_strong to increment a value, I have to do :


cur = *ptr;
while( ! compare_exchange_strong(ptr,&cur,cur+1) ) { }

(note it's a little subtle that this works - when compare_exchange_strong fails, it's because somebody else touched *ptr, so we then reload cur (this is why "old" is passed by address), so you then recompute cur+1 from the new value; so with the compare_exchange_strong, cur has a different value each time around this loop.)
But on an LL-SC architecture like ARM this becomes a loop on a loop, which is dumb when you could get the same result with a single loop :


cur = *ptr;
while( ! compare_exchange_weak(ptr,&cur,cur+1) ) { }

Note that with this loop now cur does *not* always take a new value each time around the loop (it does when it fails due to contention, but not when it fails just due to reservation-lost), but the end result is the same.
So that's why compare_exchange_weak exists, but you might ask why compare_exchange_strong exists. If we always use loops like this, then there's no need for it. But we don't always use loops like this, or we might want to loop at the much higher level. For example you might have something like :

bool SpinLock_TryLock(int * lock)
{
int zero = 0;
return compare_exchange_strong(lock,&zero,1);
}
which returns false if it couldn't get the lock (and then might do an OS wait) - you don't want to return false just because of a spurious failure. (that's not a great example, maybe I'll think of a better one later).
(BTW I think the C++0x stuff is a little bit broken, like most of C standardization, because they are trying to straddle this middle ground of exposing the efficient hardware-specific ways of doing things, but they don't actually expose enough to map directly to the hardware, and they also aren't high level enough to separate you from knowing about the hardware. For example none of their memory model actually maps directly to what x86 provides, therefore there are some very efficient x86-specific ways to do threading ops that cannot be expressed portable in C++0x. Similarly on LL-SC architectures, it would be preferrable to just have access to LL-SC directly.

I'd rather see things in the standard like "if LL-SC exist on this architecture, then they can be invoked via __ll() and __sc()" ; more generally I wish C had more conditionals built into the language, that would be so much better for real portability, as opposed to the current mess where they pretend that the language is portable but it actually isn't so you have to create your own mess of meta-language through #defines).  回復(fù)  更多評論
  


只有注冊用戶登錄后才能發(fā)表評論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国产精自产拍久久久久久| 国产精品久久久久77777| 亚洲精品中文字幕在线| 在线看一区二区| 国语自产偷拍精品视频偷| 国产三级精品在线不卡| 国产欧美日韩综合一区在线观看| 欧美肉体xxxx裸体137大胆| 欧美理论电影在线播放| 欧美日韩成人一区| 国产精品久久久久毛片软件| 国产日韩精品在线| 狠狠色狠狠色综合系列| 亚洲国产一区二区三区在线播| 亚洲国产精品一区二区第四页av| 亚洲国产精品电影在线观看| 夜夜嗨av一区二区三区四季av| 亚洲免费影视第一页| 久久国产精品亚洲77777| 免费在线观看精品| 日韩午夜av在线| 欧美一区二区三区四区在线观看| 久久综合给合| 国产精品大片免费观看| 黄色工厂这里只有精品| 亚洲视频 欧洲视频| 久久精品国内一区二区三区| 亚洲激情偷拍| av成人福利| 久久久久国产精品午夜一区| 欧美精品日韩| 国产又爽又黄的激情精品视频| 夜夜嗨av一区二区三区四季av| 久久久91精品国产| 日韩视频免费大全中文字幕| 久久久精品性| 国产精品高清网站| 亚洲理论在线| 久久精品免费| 99精品欧美| 欧美成人dvd在线视频| 国产一区二区三区久久| 一区二区三区精品在线 | 中文国产亚洲喷潮| 欧美高清在线一区二区| 亚洲欧美国产日韩天堂区| 欧美日韩色综合| 日韩一二三区视频| 欧美高清在线视频| 久久福利资源站| 国产日本欧美视频| 亚洲欧美日韩在线观看a三区| 亚洲日韩中文字幕在线播放| 久久亚洲春色中文字幕久久久| 国产视频在线观看一区| 亚洲欧美日韩久久精品| 久久综合久久综合久久综合| 欧美日韩国产综合新一区| 黄色成人在线网站| 久久中文欧美| 久久成人一区| 国产在线不卡视频| 久久在线免费| 久久久久久久97| 亚洲电影av在线| 欧美激情网站在线观看| 欧美成人日韩| 亚洲视频免费在线观看| 一区二区三区日韩在线观看| 国产精品毛片a∨一区二区三区|国| 亚洲神马久久| 欧美在线观看一区二区| 韩国福利一区| 欧美国产专区| 欧美日韩亚洲高清| 午夜视频精品| 久久网站热最新地址| 99国产精品久久久久久久久久| 一本一道久久综合狠狠老精东影业| 国产精品扒开腿做爽爽爽软件| 欧美一区二区女人| 久久久久久高潮国产精品视| 亚洲人在线视频| 亚洲一级片在线观看| 黄色成人免费网站| 亚洲美女视频在线观看| 国产精品第十页| 久久亚洲私人国产精品va媚药| 牛牛精品成人免费视频| 亚洲欧美精品一区| 久久亚洲视频| 亚洲永久免费| 蜜桃视频一区| 欧美在线观看一区| 欧美电影在线| 欧美伊久线香蕉线新在线| 玖玖玖国产精品| 亚洲素人一区二区| 欧美影片第一页| 一区二区三区日韩精品| 久久国产精品99久久久久久老狼| 亚洲美女网站| 午夜精品福利一区二区三区av | 欧美激情va永久在线播放| 中文有码久久| 久久疯狂做爰流白浆xx| 亚洲综合社区| 免费在线亚洲| 久久尤物视频| 国产精品最新自拍| 9久re热视频在线精品| 精品999在线播放| 亚洲夜间福利| 在线视频精品一| 美女精品自拍一二三四| 久久国产精品亚洲77777| 国产精品无码永久免费888| 欧美日韩一区精品| 欧美日韩八区| 久久人体大胆视频| 久久久久久久波多野高潮日日| 欧美成人免费播放| 欧美成人午夜影院| 免费久久99精品国产自在现线| 亚洲资源av| 亚洲国产精品美女| 亚洲精品少妇| 欧美91视频| 亚洲欧美激情四射在线日 | 亚洲理伦在线| 亚洲永久免费av| 欧美成人一区二免费视频软件| 日韩亚洲欧美一区二区三区| 亚洲人线精品午夜| 国色天香一区二区| 欧美一区1区三区3区公司| 中文欧美在线视频| 国产一区二区三区奇米久涩| 久久蜜桃精品| 久久夜色精品国产欧美乱极品| 欧美亚一区二区| 玉米视频成人免费看| 最新国产の精品合集bt伙计| 亚洲欧美激情一区| 女女同性精品视频| 久久久一二三| 久久gogo国模裸体人体| 在线成人激情视频| 久久久精品性| 欧美成人午夜免费视在线看片| 国内激情久久| 久久久久综合| 亚洲高清免费视频| 亚洲乱码国产乱码精品精| 蜜臀久久99精品久久久久久9| 99国产精品自拍| 欧美一区二区三区久久精品| 国产女精品视频网站免费| 亚洲欧美日产图| 久久福利一区| 黄色资源网久久资源365| 久久久久欧美精品| 亚洲福利专区| 亚洲午夜国产一区99re久久| 国产日本欧美一区二区三区| 久久久午夜电影| 亚洲人成在线播放| 西瓜成人精品人成网站| 一区二区三区中文在线观看 | 久久久久久久网站| 亚洲国产精品va在线看黑人| 亚洲综合三区| 在线日韩欧美| 国产精品视频导航| 裸体一区二区| 亚洲欧美日韩国产中文| 亚洲电影在线免费观看| 亚洲欧美一区二区在线观看| 国产欧美一区二区三区久久 | 在线观看欧美黄色| 欧美国产欧美亚洲国产日韩mv天天看完整 | 久久精品国产亚洲高清剧情介绍| 国产日产高清欧美一区二区三区| 午夜亚洲福利| 国产日韩在线亚洲字幕中文| 久久久午夜精品| 99国产精品久久久久久久成人热| 欧美一区二区视频观看视频| 亚洲国产精品精华液2区45| 欧美日韩一区二区高清| 久久er精品视频| 亚洲午夜久久久久久久久电影院| 农村妇女精品| 欧美一区在线视频| 国产精品99久久久久久有的能看 | 欧美国产在线电影| 久久国产精品一区二区三区四区| 日韩午夜电影av| 亚洲精品1234| 亚洲国产成人一区|