• <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>
            franksunny的個(gè)人技術(shù)空間
            獲得人生中的成功需要的專注與堅(jiān)持不懈多過天才與機(jī)會。 ——C.W. Wendte

            Active Object (AO) 框架,是Symbian的基本工作部分。它是為了滿足多個(gè)任務(wù)同時(shí)執(zhí)行的要求。在 Windows/Unix 平臺上,我們可以不加思索的使用多線程來完成多任務(wù)??墒窃谇度胧狡脚_上,系統(tǒng)的資源是有限的。比如CPU、內(nèi)存都比我們平時(shí)用的個(gè)人計(jì)算機(jī)要低。這就要求嵌入式系統(tǒng)能夠合理的使用系統(tǒng)資源。不能頻繁的切換線程或者進(jìn)程。

            Symbian為這種特別需求設(shè)計(jì)了Active Object (AO)框架。AO框架是運(yùn)行于一個(gè)線程內(nèi)部的調(diào)度框架。其基本思想就是把一個(gè)單線程分為多個(gè)時(shí)間片,來運(yùn)行不同的任務(wù)

            這和多線程有很大區(qū)別。多線程之間是可以被搶占的(由操作系統(tǒng)調(diào)度),但是AO框架中的各個(gè)任務(wù)是不可被搶占的,一個(gè)任務(wù)必須完成,才能開始下一個(gè)任務(wù)。

            下面是多線程和AO框架的簡單比較:

            多線程                                       AO框架

            可以被搶占                                   不可被搶占

            上下文切換耗費(fèi)CPU時(shí)間                       沒有上下文切換

            由操作系統(tǒng)調(diào)度                               由線程自己的AO框架調(diào)度

            每個(gè)線程都有至少4K Stack.                    AO沒有單獨(dú)的Stack.

            操作系統(tǒng)還要分配額外的資源記錄線程            只是一個(gè)Active Object.

            Symbian系統(tǒng)本身使用了大量的AO框架來實(shí)現(xiàn)一些系統(tǒng)服務(wù)。這使得Symbian和其他嵌入式系統(tǒng)相比較,對系統(tǒng)資源的使用更加合理。

            AO框架包括CActiveScheduler CActive (Active Object)。一個(gè)線程的所有的Active Object對象都被安裝在該線程的CActiveScheduler對象內(nèi).CActiveScheduler對象監(jiān)控每個(gè)Active Object是否完成了當(dāng)前任務(wù),如果完成了,就調(diào)度下一個(gè)Active Object來執(zhí)行。CActiveScheduler根據(jù)優(yōu)先級來調(diào)度各個(gè)Active Object.

             

            關(guān)于CActiveScheduler的創(chuàng)建和安裝,CActive的創(chuàng)建和安裝,和CActive的任務(wù)處理,可以參看 SDK 文檔。理解起來不難。下面要說一個(gè)比較容易忽略的地方。這對理解AO框架非常重要。

            創(chuàng)建調(diào)度器:

            CActiveScheduler * scheduler = new (ELeave) CActiveScheduler;

            CleanupStack::PushL(scheduler);

            CActiveScheduler::Install(scheduler);

             

            運(yùn)行調(diào)度器:

            CActiveScheduler::Start();

             

            停止調(diào)度器:

            CActiveScheduler::Stop();

             

            以上代碼都是運(yùn)行在一個(gè)線程中的,一般來講,一個(gè)EXE只有一個(gè)主線程.

            可是如果真的有2個(gè)線程呢?

            為什么在當(dāng)前線程下調(diào)用CActiveScheduler::Start(),CActiveScheduler::Stop()運(yùn)行/停止的就是當(dāng)前線程的調(diào)度器而不是另一個(gè)線程的調(diào)度器?

            每個(gè)線程都有自己的CActiveScheduler,那么這個(gè)CActiveScheduler類是怎么調(diào)用CActiveScheduler::Start(),CActiveScheduler::Stop()來運(yùn)行/停止當(dāng)前的調(diào)度器的呢?

            我們看到Start/Stop并沒有參數(shù).

            打開CActiveScheduler的類定義:

            class CActiveScheduler : public CBase

                {

            public:

                IMPORT_C CActiveScheduler();

                IMPORT_C ~CActiveScheduler();

                IMPORT_C static void Install(CActiveScheduler* aScheduler);

                IMPORT_C static CActiveScheduler* Current();

                IMPORT_C static void Add(CActive* anActive);

                IMPORT_C static void Start();

                IMPORT_C static void Stop();

                IMPORT_C static TBool RunIfReady(TInt& aError, TInt aMinimumPriority);

                IMPORT_C static CActiveScheduler* Replace(CActiveScheduler* aNewActiveScheduler);

                IMPORT_C virtual void WaitForAnyRequest();

                IMPORT_C virtual void Error(TInt anError) const;

            private:

                void DoStart();

                void OwnedStartLoop(TInt& aRunning);

                IMPORT_C virtual void OnStarting();

                IMPORT_C virtual void OnStopping();

                IMPORT_C virtual void Reserved_1();

                IMPORT_C virtual void Reserved_2();

            private:

                // private interface used through by CActiveSchedulerWait objects

                friend class CActiveSchedulerWait;

                static void OwnedStart(CActiveSchedulerWait& aOwner);

            protected:

                inline TInt Level() const;

            private:

                TInt iLevel;

                TPriQue<CActive> iActiveQ;

                };

             

            我們并沒有看到靜態(tài)的成員來表示線程,但是卻有一個(gè)static函數(shù)CActiveScheduler* Current();返回當(dāng)前線程的調(diào)度器.

            現(xiàn)在猜想奧秘就在這個(gè)函數(shù)是怎么實(shí)現(xiàn)的。這個(gè)靜態(tài)的函數(shù)怎么就能得到當(dāng)前這個(gè)運(yùn)行線程的調(diào)度器,而不是別的線程的調(diào)度器。我們可以猜想,肯定是Current()內(nèi)部實(shí)現(xiàn)能取到當(dāng)前線程的標(biāo)識信息.用這個(gè)標(biāo)識,靜態(tài)函數(shù)能取到這個(gè)線程的CActiveScheduler.這個(gè)具體如何實(shí)現(xiàn)呢?

            答案就是:當(dāng)前線程的線程ID可以這樣得到:

            創(chuàng)建一個(gè)缺省的線程對象:

            RThread thread;

            取得當(dāng)前線程的ID:

            TThreadId threadId = thread.Id();

            能得到當(dāng)前線程的threadId,當(dāng)然可以得到和當(dāng)前線程關(guān)聯(lián)的CActiveScheduler。因此以上兩個(gè)問題也就迎刃而解了,在一個(gè)線程內(nèi)調(diào)用CActiveScheduler::Start(),CActiveScheduler::Stop()開啟的就是當(dāng)前線程。

            既然回復(fù)了上面的問題,那么我們自然就能明確,在一個(gè)線程內(nèi)是不能通過StartStop函數(shù)來開啟和停止另一個(gè)線程內(nèi)的活動對象規(guī)劃器CActiveScheduler。

             

            補(bǔ)充點(diǎn)其他東西:

            Symbian操作系統(tǒng)中,每個(gè)進(jìn)程都有一個(gè)或多個(gè)線程。線程是執(zhí)行的基本單位。一個(gè)進(jìn)程的主線程是在進(jìn)程啟動時(shí)生成的。Symbian屬于搶占式多任務(wù)操作系統(tǒng),這意味著每個(gè)線程都有自己的執(zhí)行時(shí)間,直到系統(tǒng)將CPU使用權(quán)給予其他線程。當(dāng)系統(tǒng)調(diào)度時(shí),具有最高優(yōu)先權(quán)的線程將首先獲得執(zhí)行。

            進(jìn)程邊界是受內(nèi)存保護(hù)的。所有的用戶進(jìn)程都有自己的內(nèi)存地址空間,同一進(jìn)程中的所有線程共享這一空間,用戶進(jìn)程不能直接訪問其他進(jìn)程的地址空間。

            每個(gè)線程都有它自己的stackheap,這里heap可以是私有的,也可以被其他線程共享。應(yīng)用程序框架生成并安裝了一個(gè)active scheduler,并且為主線程準(zhǔn)備了清除棧。如果沒有使用框架(如編寫exe程序)那就要手動生成這些了。

            Symbian操作系統(tǒng)專為單線程應(yīng)用優(yōu)化,因此強(qiáng)烈推薦使用“活動對象”代替多線程。

            posted on 2008-10-11 20:34 frank.sunny 閱讀(2687) 評論(2)  編輯 收藏 引用 所屬分類: symbian 開發(fā)

            FeedBack:
            # re: 從線程角度看AO框架
            2008-10-12 07:36 | luke
            這個(gè)感覺就是一個(gè)在用戶層調(diào)度的線程,類似所謂的“纖程”概念,不知道是否這樣?  回復(fù)  更多評論
              
            # re: 從線程角度看AO框架
            2008-10-12 08:19 | frank.sunny
            @luke
            謝謝luke,你的提點(diǎn)很有用,我對Windows核心編程之前了解的并不多,在你提點(diǎn)下,又去查了下

            進(jìn)程通常被定義為一個(gè)正在運(yùn)行的程序的實(shí)例
            線程是cpu分配的基本單位
            進(jìn)程是不活潑的。進(jìn)程從來不執(zhí)行任何東西,它只是線程的容器。線程總是在某個(gè)進(jìn)程環(huán)境中創(chuàng)建的,而且它的整個(gè)壽命期都在該進(jìn)程中。單個(gè)進(jìn)程可能包含若干個(gè)線程,所有這些線程都“同時(shí)”執(zhí)行進(jìn)程地址空間中的代碼。
            這個(gè)可能大家都知道的

            纖程是以用戶方式代碼來實(shí)現(xiàn)的,內(nèi)核并不知道纖程,并且它們是根據(jù)用戶定義的算法來調(diào)度的。由于你定義了纖程的調(diào)度算法,因此,就內(nèi)核而言,纖程采用非搶占式調(diào)度方式。
            需要了解的下一個(gè)問題是,單線程可以包含一個(gè)或多個(gè)纖程。就內(nèi)核而言,線程是搶占調(diào)度的,是正在執(zhí)行的代碼。然而,線程每次執(zhí)行一個(gè)纖程的代碼—你決定究竟執(zhí)行哪個(gè)纖程。
            雖然我不知道symbianOS內(nèi)核開發(fā)的時(shí)候是怎么樣的,但是我根據(jù)symbian活動對象的原理來分析,的確應(yīng)該就是“纖程”的影子,再次感謝luke的提點(diǎn)  回復(fù)  更多評論
              

            常用鏈接

            留言簿(13)

            隨筆分類

            個(gè)人其它博客

            基礎(chǔ)知識鏈接

            最新評論

            閱讀排行榜

            評論排行榜

            国产成人香蕉久久久久| 久久国产精品国语对白| 久久综合鬼色88久久精品综合自在自线噜噜| 精品久久久久久无码专区| 精品久久久噜噜噜久久久 | 久久精品视频免费| 国产精品成人久久久久久久 | 久久久国产亚洲精品| 久久免费的精品国产V∧| 久久精品无码一区二区三区免费| 久久久久久精品成人免费图片| 国产精品久久波多野结衣| 久久伊人五月丁香狠狠色| 国产精品美女久久久久av爽| 久久人人爽人人人人爽AV| 伊人久久免费视频| 久久综合久久综合久久| 精品熟女少妇a∨免费久久| 久久久久亚洲爆乳少妇无| 国产精品久久久久久久久久免费| 99久久做夜夜爱天天做精品| 精品久久久久久99人妻| 久久国产精品99久久久久久老狼| 久久久久亚洲AV无码观看| 国产精品免费久久久久影院| 国产高潮国产高潮久久久| 一本色道久久88精品综合| 中文字幕久久久久人妻| 亚洲国产精品狼友中文久久久| 久久久久久久综合日本| 久久精品国产91久久麻豆自制 | 99久久做夜夜爱天天做精品| 久久精品无码免费不卡| 久久99国产一区二区三区| 亚洲国产精品久久久久婷婷软件| 国内精品久久久久影院日本| 亚洲国产精品无码久久久蜜芽| 亚洲乱码精品久久久久..| 久久精品中文无码资源站| 综合网日日天干夜夜久久| 久久久久久夜精品精品免费啦|