女人被狂躁到高潮视频免费无遮挡,内射人妻骚骚骚,免费人成小说在线观看网站,九九影院午夜理论片少妇,免费av永久免费网址

當(dāng)前位置:首頁(yè) > > 充電吧
[導(dǎo)讀]考慮到移植以及靈活性,LevelDB將系統(tǒng)相關(guān)的處理(文件/進(jìn)程/時(shí)間)抽象成Evn,用戶可以自己實(shí)現(xiàn)相應(yīng)的接口,作為option的一部分傳入,默認(rèn)使用自帶的實(shí)現(xiàn)。?env.h中聲明了:虛基類(lèi)env,


考慮到移植以及靈活性,LevelDB將系統(tǒng)相關(guān)的處理(文件/進(jìn)程/時(shí)間)抽象成Evn,用戶可以自己實(shí)現(xiàn)相應(yīng)的接口,作為option的一部分傳入,默認(rèn)使用自帶的實(shí)現(xiàn)。?
env.h中聲明了:

虛基類(lèi)env,在env_posix.cc中,派生類(lèi)PosixEnv繼承自env類(lèi),是LevelDB的默認(rèn)實(shí)現(xiàn)。虛基類(lèi)WritableFile、SequentialFile、RandomAccessFile,分別是文件的寫(xiě)抽象類(lèi),順序讀抽象類(lèi)和隨機(jī)讀抽象類(lèi)類(lèi)Logger,log文件的寫(xiě)入接口,log文件是防止系統(tǒng)異常終止造成數(shù)據(jù)丟失,是memtable在磁盤(pán)的備份類(lèi)FileLock,為文件上鎖WriteStringToFile、ReadFileToString、Log三個(gè)全局函數(shù),封裝了上述接口

下面來(lái)看看env_posix.cc中為我們寫(xiě)好的默認(rèn)實(shí)現(xiàn)

順序讀:


class?PosixSequentialFile:?public?SequentialFile?{
?private:
??std::string?filename_;
??FILE*?file_;

?public:
??PosixSequentialFile(const?std::string&?fname,?FILE*?f)
????:?filename_(fname),?file_(f)?{?}
??virtual?~PosixSequentialFile()?{?fclose(file_);?}
??//?從文件中讀取n個(gè)字節(jié)存放到?"scratch[0..n-1]",?然后將"scratch[0..n-1]"轉(zhuǎn)化為Slice類(lèi)型并存放到*result中
??//?如果正確讀取,則返回OK?status,否則返回non-OK?status
??virtual?Status?Read(size_t?n,?Slice*?result,?char*?scratch)?{
??Status?s;
#ifdef?BSD
??//?fread_unlocked?doesn't?exist?on?FreeBSD
??size_t?r?=?fread(scratch,?1,?n,?file_);
#else
??//?size_t?fread_unlocked(void?*ptr,?size_t?size,?size_t?n,FILE?*stream);
??//?ptr:用于接收數(shù)據(jù)的內(nèi)存地址
??//?size:要讀的每個(gè)數(shù)據(jù)項(xiàng)的字節(jié)數(shù),單位是字節(jié)
??//?n:要讀n個(gè)數(shù)據(jù)項(xiàng),每個(gè)數(shù)據(jù)項(xiàng)size個(gè)字節(jié)
??//?stream:輸入流
??//?返回值:返回實(shí)際讀取的數(shù)據(jù)大小
??//?因?yàn)楹瘮?shù)名帶了"_unlocked"后綴,所以它不是線程安全的
??size_t?r?=?fread_unlocked(scratch,?1,?n,?file_);
#endif
??//?Slice的第二個(gè)參數(shù)要用實(shí)際讀到的數(shù)據(jù)大小,因?yàn)樽x到文件尾部,剩下的字節(jié)數(shù)可能小于n
??*result?=?Slice(scratch,?r);
??if?(r?<?n)?{
????if?(feof(file_))?{
????//?We?leave?status?as?ok?if?we?hit?the?end?of?the?file
????//?如果r<n,且feof(file_)非零,說(shuō)明到了文件結(jié)尾,什么都不用做,函數(shù)結(jié)束后會(huì)返回OK?Status
????}?else?{
????//?A?partial?read?with?an?error:?return?a?non-ok?status
????//?否則返回錯(cuò)誤信息
????s?=?Status::IOError(filename_,?strerror(errno));
????}
??}
??return?s;
??}
??//?跳過(guò)n字節(jié)的內(nèi)容,這并不比讀取n字節(jié)的內(nèi)容慢,而且會(huì)更快。
??//?如果到達(dá)了文件尾部,則會(huì)停留在文件尾部,并返回OK?Status。
??//?否則,返回錯(cuò)誤信息
??virtual?Status?Skip(uint64_t?n)?{
???//?int?fseek(FILE?*stream,?long?offset,?int?origin);
???//?stream:文件指針
???//?offset:偏移量,整數(shù)表示正向偏移,負(fù)數(shù)表示負(fù)向偏移
???//?origin:設(shè)定從文件的哪里開(kāi)始偏移,?可能取值為:SEEK_CUR、?SEEK_END?或?SEEK_SET
???//?SEEK_SET:?文件開(kāi)頭
???//?SEEK_CUR:?當(dāng)前位置
???//?SEEK_END:?文件結(jié)尾
???//?其中SEEK_SET,?SEEK_CUR和SEEK_END和依次為0,1和2.
???//?舉例:
???//?fseek(fp,?100L,?0);?把fp指針移動(dòng)到離文件開(kāi)頭100字節(jié)處;
???//?fseek(fp,?100L,?1);?把fp指針移動(dòng)到離文件當(dāng)前位置100字節(jié)處;
???//?fseek(fp,?100L,?2);?把fp指針退回到離文件結(jié)尾100字節(jié)處。
???//?返回值:成功返回0,失敗返回非0
??if?(fseek(file_,?n,?SEEK_CUR))?{
????return?Status::IOError(filename_,?strerror(errno));
??}
??return?Status::OK();
??}
};

這就是LevelDB從磁盤(pán)順序讀取文件的接口了,用的是C的流文件操作和FILE結(jié)構(gòu)體。需要注意的是Read接口讀取文件時(shí)不會(huì)鎖住文件流,因此外部的并發(fā)訪問(wèn)需要自行提供并發(fā)控制。
隨機(jī)讀:


class?PosixRandomAccessFile:?public?RandomAccessFile?{
?private:
??std::string?filename_;
??int?fd_;
??mutable?boost::mutex?mu_;

?public:
??PosixRandomAccessFile(const?std::string&?fname,?int?fd)
????:?filename_(fname),?fd_(fd)?{?}
??virtual?~PosixRandomAccessFile()?{?close(fd_);?}
??//?這里與順序讀的同名函數(shù)相比,多了一個(gè)參數(shù)offset,offset用來(lái)指定
??//?讀取位置距離文件起始位置的偏移量,這樣就可以實(shí)現(xiàn)隨機(jī)讀了。
??virtual?Status?Read(uint64_t?offset,?size_t?n,?Slice*?result,
????????????char*?scratch)?const?{
????Status?s;
#ifdef?WIN32
????//?no?pread?on?Windows?so?we?emulate?it?with?a?mutex
????boost::unique_locklock(mu_);

????if?(::_lseeki64(fd_,?offset,?SEEK_SET)?==?-1L)?{
??????return?Status::IOError(filename_,?strerror(errno));
????}
	//?int?_read(int?_FileHandle,?void?*?_DstBuf,?unsigned?int?_MaxCharCount)
	//?_FileHandle:文件描述符
	//?_DstBuf:保存讀取數(shù)據(jù)的緩沖區(qū)
	//?_MaxCharCount:讀取的字節(jié)數(shù)
	//?返回值:成功返回讀取的字節(jié)數(shù),出錯(cuò)返回-1并設(shè)置errno。
????int?r?=?::_read(fd_,?scratch,?n);
????*result?=?Slice(scratch,?(r?<?0)???0?:?r);
????lock.unlock();
#else
	//?在非windows系統(tǒng)上使用pread進(jìn)行隨機(jī)讀,為何此時(shí)不用鎖呢?詳見(jiàn)下文分析
????ssize_t?r?=?pread(fd_,?scratch,?n,?static_cast(offset));
????*result?=?Slice(scratch,?(r?<?0)???0?:?r);
#endif
????if?(r?<?0)?{
??????//?An?error:?return?a?non-ok?status
??????s?=?Status::IOError(filename_,?strerror(errno));
????}
????return?s;
??}
};



可以看到的是,PosixRandomAccessFile 在非windows系統(tǒng)上使用了 pread 來(lái)實(shí)現(xiàn)原子的定位加訪問(wèn)功能。常規(guī)的隨機(jī)訪問(wèn)文件的過(guò)程可以分為兩步,fseek (seek) 定位到訪問(wèn)點(diǎn),調(diào)用 fread (read) 來(lái)從特定位置開(kāi)始訪問(wèn) FILE* (fd)。然而,這兩個(gè)操作組合在一起并不是原子的,即 fseek 和 fread 之間可能會(huì)插入其他線程的文件操作。相比之下 pread 由系統(tǒng)來(lái)保證實(shí)現(xiàn)原子的定位和讀取組合功能。需要注意的是,pread 操作不會(huì)更新文件指針。

需要注意的是,在隨機(jī)讀和順序讀中,分別用fd和FILE *來(lái)表示一個(gè)文件。文件描述符(file descriptor)是系統(tǒng)層的概念, fd 對(duì)應(yīng)于系統(tǒng)打開(kāi)文件表里面的一個(gè)文件;FILE* 是應(yīng)用層的概念,其包含了應(yīng)用層操作文件的數(shù)據(jù)結(jié)構(gòu)。

順序?qū)懀?/p>


class?BoostFile?:?public?WritableFile?{

public:
??explicit?BoostFile(std::string?path)?:?path_(path),?written_(0)?{
????Open();
??}

??virtual?~BoostFile()?{
????Close();
??}

private:
??void?Open()?{
????//?we?truncate?the?file?as?implemented?in?env_posix
	?//?trunc:先將文件中原有的內(nèi)容清空
	?//?out:為輸出(寫(xiě))而打開(kāi)文件
	?//?binary:以二進(jìn)制方式打開(kāi)文件
?????file_.open(path_.generic_string().c_str(),?
?????????std::ios_base::trunc?|?std::ios_base::out?|?std::ios_base::binary);
?????written_?=?0;
??}

public:
??virtual?Status?Append(const?Slice&?data)?{
????Status?result;
????file_.write(data.data(),?data.size());
????if?(!file_.good())?{
??????result?=?Status::IOError(
??????????path_.generic_string()?+?"?Append",?"cannot?write");
????}
????return?result;
??}

??virtual?Status?Close()?{
????Status?result;

????try?{
??????if?(file_.is_open())?{
????????Sync();
	//?關(guān)閉流時(shí),緩沖區(qū)中的數(shù)據(jù)會(huì)自動(dòng)寫(xiě)入到文件
	//?上面調(diào)用Sync()強(qiáng)制刷新,是為了確保數(shù)據(jù)寫(xiě)入,防止數(shù)據(jù)丟失
????????file_.close();
??????}
????}?catch?(const?std::exception?&?e)?{
??????result?=?Status::IOError(path_.generic_string()?+?"?close",?e.what());
????}

????return?result;
??}

??virtual?Status?Flush()?{
????file_.flush();
????return?Status::OK();
??}
??//?手動(dòng)刷新(清空輸出緩沖區(qū),并把緩沖區(qū)內(nèi)容同步到文件)
??virtual?Status?Sync()?{
????Status?result;
????try?{
??????Flush();
????}?catch?(const?std::exception?&?e)?{
??????result?=?Status::IOError(path_.string()?+?"?sync",?e.what());
????}

????return?result;
??}

private:
??boost::filesystem::path?path_;
??boost::uint64_t?written_;
??std::ofstream?file_;
};


關(guān)于ofstream::flush和ofstream::Close的區(qū)別,詳見(jiàn):C++之ofstream::flush與ofstream::close

文件鎖:


class?BoostFileLock?:?public?FileLock?{
?public:
??boost::interprocess::file_lock?fl_;
};
virtual?Status?LockFile(const?std::string&?fname,?FileLock**?lock)?{
????*lock?=?NULL;

????Status?result;

????try?{
??????if?(!boost::filesystem::exists(fname))?{
????????std::ofstream?of(fname,?std::ios_base::trunc?|?std::ios_base::out);
??????}

??????assert(boost::filesystem::exists(fname));

??????boost::interprocess::file_lock?fl(fname.c_str());
??????BoostFileLock?*?my_lock?=?new?BoostFileLock();
??????my_lock->fl_?=?std::move(fl);
??????if?(my_lock->fl_.try_lock())
????????*lock?=?my_lock;
??????else
????????result?=?Status::IOError("acquiring?lock?"?+?fname?+?"?failed");
????}?catch?(const?std::exception?&?e)?{
??????result?=?Status::IOError("lock?"?+?fname,?e.what());
????}

????return?result;
??}
?virtual?Status?UnlockFile(FileLock*?lock)?{

????Status?result;

????try?{
??????BoostFileLock?*?my_lock?=?static_cast(lock);
??????my_lock->fl_.unlock();
??????delete?my_lock;
????}?catch?(const?std::exception?&?e)?{
??????result?=?Status::IOError("unlock",?e.what());
????}

????return?result;
??}

文件的鎖操作是調(diào)用Boost的鎖實(shí)現(xiàn)的。加鎖是為了防止多進(jìn)程的并發(fā)沖突,如果加鎖失敗,*lock=NULL,且返回non-OK;如果加鎖成功,*lock存放的的是鎖的指針,并返回OK。如果進(jìn)程退出,鎖會(huì)自動(dòng)釋放,否則用戶需要調(diào)用UnlockFile顯式的釋放鎖。


這幾個(gè)方法都非常簡(jiǎn)單,比較晦澀的是這句:my_lock->std::move(f1),從函數(shù)名來(lái)看,是要移動(dòng)f1。其實(shí)std::move是C++11標(biāo)準(zhǔn)庫(kù)在

計(jì)劃任務(wù):

PosixEnv還有一個(gè)很重要的功能,計(jì)劃任務(wù),也就是后臺(tái)的compaction線程。compaction就是壓縮合并的意思,在LevelDB源碼分析之六:skiplist(2)中也有提到。對(duì)于LevelDB來(lái)說(shuō),寫(xiě)入記錄操作很簡(jiǎn)單,刪除記錄僅僅寫(xiě)入一個(gè)刪除標(biāo)記就算完事,但是讀取記錄比較復(fù)雜,需要在內(nèi)存以及各個(gè)層級(jí)文件中依照新鮮程度依次查找,代價(jià)很高。為了加快讀取速度,LevelDB采取了compaction的方式來(lái)對(duì)已有的記錄進(jìn)行整理壓縮,通過(guò)這種方式,來(lái)刪除掉一些不再有效的KV數(shù)據(jù),減小數(shù)據(jù)規(guī)模,減少文件數(shù)量等。

PosixEnv中定義了一個(gè)任務(wù)隊(duì)列:


??struct?BGItem?{?void*?arg;?void?(*function)(void*);?};
??//用的是deque雙端隊(duì)列作為底層的數(shù)據(jù)結(jié)構(gòu)
??typedef?std::dequeBGQueue;
??BGQueue?queue_;

主線程一旦判定需要進(jìn)行compaction操作,就把compaction任務(wù)壓進(jìn)隊(duì)列queue_中,BGItem是存有任務(wù)函數(shù)和db對(duì)象指針的結(jié)構(gòu)。而后臺(tái)線程從一開(kāi)始就不斷根據(jù)隊(duì)列中的函數(shù)指針執(zhí)行compaction任務(wù)。BGThread()函數(shù)就是不停的在queue_中取出函數(shù)指針,執(zhí)行。



后臺(tái)進(jìn)程一直執(zhí)行queue_中的任務(wù),由于queue_是動(dòng)態(tài)的,自然需要考慮queue_空了怎么辦,LevelDB采用的是條件變量boost::condition_variable bgsignal_,隊(duì)列空了就進(jìn)入等待,直至有新的任務(wù)加入進(jìn)來(lái)。而條件變量一般是要和boost::mutex mu_搭配使用,防止某些邏輯錯(cuò)誤。


?//?BGThread函數(shù)的包裝,里面調(diào)用的就是BGThread函數(shù)
??static?void*?BGThreadWrapper(void*?arg)?{
????reinterpret_cast(arg)->BGThread();
????return?NULL;
??}
void?PosixEnv::Schedule(void?(*function)(void*),?void*?arg)?{
??boost::unique_locklock(mu_);

??//?Start?background?thread?if?necessary
??if?(!bgthread_)?{
?????bgthread_.reset(
?????????new?boost::thread(boost::bind(&PosixEnv::BGThreadWrapper,?this)));
??}

??//?Add?to?priority?queue
??//?將任務(wù)壓進(jìn)隊(duì)列中
??queue_.push_back(BGItem());
??queue_.back().function?=?function;
??queue_.back().arg?=?arg;

??lock.unlock();

??bgsignal_.notify_one();

}
void?PosixEnv::BGThread()?{
??while?(true)?{
??//?加鎖,防止并發(fā)沖突
??boost::unique_locklock(mu_);
??//?如果隊(duì)列為空,等待,直到收到通知(notification)
??while?(queue_.empty())?{
????bgsignal_.wait(lock);
??}
??//?從隊(duì)列頭取出任務(wù)的函數(shù)及其參數(shù)
??void?(*function)(void*)?=?queue_.front().function;
??void*?arg?=?queue_.front().arg;
??queue_.pop_front();

??lock.unlock();
??//?調(diào)用函數(shù)
??(*function)(arg);
??}
}

此外PosixEnv中還有FileExists、GetChildren、DeleteFile、CreateDir、DeleteDir、GetFileSize、RenameFile等等函數(shù),他們見(jiàn)名知義,都是調(diào)用Boot的相應(yīng)函數(shù)實(shí)現(xiàn)的。


EnvWrapper:

在levelDB中還實(shí)現(xiàn)了一個(gè)EnvWrapper類(lèi),該類(lèi)繼承自Env,且只有一個(gè)成員函數(shù)Env* target_,該類(lèi)的所有變量都調(diào)用Env類(lèi)相應(yīng)的成員變量,我們知道,Env是一個(gè)抽象類(lèi),是不能定義Env 類(lèi)型的對(duì)象的。我們傳給EnvWrapper 的構(gòu)造函數(shù)的類(lèi)型是PosixEnv,所以,最后調(diào)用的都是PosixEnv類(lèi)的成員變量,你可能已經(jīng)猜到了,這就是設(shè)計(jì)模式中的代理模式,EnvWrapper只是進(jìn)行了簡(jiǎn)單的封裝,它的代理了Env的子類(lèi)PosixEnv。
EnvWrapper和Env與PosixEnv的關(guān)系如下:


由于篇幅限制,Env中的Logger類(lèi)就放在后面分析了,參考:LevelDB源碼分析之十:LOG文件,從env給我的收獲就是:

利用虛基類(lèi)的特性提供了默認(rèn)的實(shí)現(xiàn),也開(kāi)放了用戶自定義操作的權(quán)限面向?qū)ο缶幊谭妒降膶W(xué)習(xí),把一切操作定義成類(lèi)文件的加鎖解鎖,線程的同步C的文件流操作,對(duì)文件名的字符提取操作,創(chuàng)建、刪除文件和路徑,這些都可以直接用到將來(lái)自己的項(xiàng)目中參考.



本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專(zhuān)欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

LED驅(qū)動(dòng)電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關(guān)鍵字: 驅(qū)動(dòng)電源

在工業(yè)自動(dòng)化蓬勃發(fā)展的當(dāng)下,工業(yè)電機(jī)作為核心動(dòng)力設(shè)備,其驅(qū)動(dòng)電源的性能直接關(guān)系到整個(gè)系統(tǒng)的穩(wěn)定性和可靠性。其中,反電動(dòng)勢(shì)抑制與過(guò)流保護(hù)是驅(qū)動(dòng)電源設(shè)計(jì)中至關(guān)重要的兩個(gè)環(huán)節(jié),集成化方案的設(shè)計(jì)成為提升電機(jī)驅(qū)動(dòng)性能的關(guān)鍵。

關(guān)鍵字: 工業(yè)電機(jī) 驅(qū)動(dòng)電源

LED 驅(qū)動(dòng)電源作為 LED 照明系統(tǒng)的 “心臟”,其穩(wěn)定性直接決定了整個(gè)照明設(shè)備的使用壽命。然而,在實(shí)際應(yīng)用中,LED 驅(qū)動(dòng)電源易損壞的問(wèn)題卻十分常見(jiàn),不僅增加了維護(hù)成本,還影響了用戶體驗(yàn)。要解決這一問(wèn)題,需從設(shè)計(jì)、生...

關(guān)鍵字: 驅(qū)動(dòng)電源 照明系統(tǒng) 散熱

根據(jù)LED驅(qū)動(dòng)電源的公式,電感內(nèi)電流波動(dòng)大小和電感值成反比,輸出紋波和輸出電容值成反比。所以加大電感值和輸出電容值可以減小紋波。

關(guān)鍵字: LED 設(shè)計(jì) 驅(qū)動(dòng)電源

電動(dòng)汽車(chē)(EV)作為新能源汽車(chē)的重要代表,正逐漸成為全球汽車(chē)產(chǎn)業(yè)的重要發(fā)展方向。電動(dòng)汽車(chē)的核心技術(shù)之一是電機(jī)驅(qū)動(dòng)控制系統(tǒng),而絕緣柵雙極型晶體管(IGBT)作為電機(jī)驅(qū)動(dòng)系統(tǒng)中的關(guān)鍵元件,其性能直接影響到電動(dòng)汽車(chē)的動(dòng)力性能和...

關(guān)鍵字: 電動(dòng)汽車(chē) 新能源 驅(qū)動(dòng)電源

在現(xiàn)代城市建設(shè)中,街道及停車(chē)場(chǎng)照明作為基礎(chǔ)設(shè)施的重要組成部分,其質(zhì)量和效率直接關(guān)系到城市的公共安全、居民生活質(zhì)量和能源利用效率。隨著科技的進(jìn)步,高亮度白光發(fā)光二極管(LED)因其獨(dú)特的優(yōu)勢(shì)逐漸取代傳統(tǒng)光源,成為大功率區(qū)域...

關(guān)鍵字: 發(fā)光二極管 驅(qū)動(dòng)電源 LED

LED通用照明設(shè)計(jì)工程師會(huì)遇到許多挑戰(zhàn),如功率密度、功率因數(shù)校正(PFC)、空間受限和可靠性等。

關(guān)鍵字: LED 驅(qū)動(dòng)電源 功率因數(shù)校正

在LED照明技術(shù)日益普及的今天,LED驅(qū)動(dòng)電源的電磁干擾(EMI)問(wèn)題成為了一個(gè)不可忽視的挑戰(zhàn)。電磁干擾不僅會(huì)影響LED燈具的正常工作,還可能對(duì)周?chē)娮釉O(shè)備造成不利影響,甚至引發(fā)系統(tǒng)故障。因此,采取有效的硬件措施來(lái)解決L...

關(guān)鍵字: LED照明技術(shù) 電磁干擾 驅(qū)動(dòng)電源

開(kāi)關(guān)電源具有效率高的特性,而且開(kāi)關(guān)電源的變壓器體積比串聯(lián)穩(wěn)壓型電源的要小得多,電源電路比較整潔,整機(jī)重量也有所下降,所以,現(xiàn)在的LED驅(qū)動(dòng)電源

關(guān)鍵字: LED 驅(qū)動(dòng)電源 開(kāi)關(guān)電源

LED驅(qū)動(dòng)電源是把電源供應(yīng)轉(zhuǎn)換為特定的電壓電流以驅(qū)動(dòng)LED發(fā)光的電壓轉(zhuǎn)換器,通常情況下:LED驅(qū)動(dòng)電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關(guān)鍵字: LED 隧道燈 驅(qū)動(dòng)電源
關(guān)閉