producer and consumer concept ( II )

上一回,我們談到生產者與消費者的關係和資料前後一致性的特性。

在一個系統中,因為存取的動作複雜,產生許許多多不同的死結。因為有人試著把存取的動作規劃出優先順序,減少存取時會發生的死結。

在把優先順序說出來以前,我們要先把存取的動作歸納出基本的含意。然後才能把順序制定出來。

名詞解釋:

PMW: 這是一個posted write的動作。也就是說master 發出一筆 write data到slave。當送出這個動作後,master就不管是否真的會到slave。也就是說master在發出 write data後,就不負有任何的責任。

DRR:這是一個non-posed read的動作。也就是說master發出一筆 read data到slave。當送出這個動作後,master還是繼續等待slave的回覆。也就是說master在發出 read data後,還負對資料回來的責任。

DWR:這是一個non-posed write的動作。也就是說master發出一筆 write data到slave。當送出這個動作後,master還是繼續等待slave的回覆,確保資料是真的被寫到slave。也就是說master在發出 write data後,還負有對正確寫入的責任。

DRC: 這是一個回覆read的動作,也就是如果master有發出一筆 read data 到slave,那他就會等到slave回覆的DRC封包,得到它想要的資料及狀態。

DWC: 這是一個回覆 write 的動作,也就是如果master有發出一筆 write data 到slave,那他就會等到slave回覆的DWC封包,得到它想要的資料及狀態。

Posted: 指 master 送出去的命令後,即失去對它的責任。它有沒有正確到達目的地是別人的責任,不是 master的。

Non-posted:指 master 送出去的命令後,還負有對它的責任。它有沒有正確到達目的地是 master關心的事情。

 

FIg1: system with complex devices.

 

PCI ordering rule. 

 

Table: PCI ordering rule. 

Row是指隨後而來的的命令。而Col是指先前發出的命令。所以(Col, Row)則是指Col指令排在Row之前。所以我們來看看這個表格。

 

Rule1: 指(Col 2,Row 1),指一個PMW和PMW的順序,也就是說兩個相同的posted write指令,後面的posted write是否可以超前posted write。答案是不行。如果接受端對於收到資料是有順序性的,隨便違反順序是會讓系統出錯的。

Rule2: 指(Col 2,Row 2),指non-posted read是否可以超前posted write,答案是不行。如果這兩筆是指向相同的位址,那non-posted read超前posted write,不就讀到不正確的資料。

Rule3: 指(Col 2,Row 3),指non-posted write是否可以超posted write,答案是不行。就如同之前提過的生產者與消費者的模型。當生產者寫完資料後,還要把status清除為0。如果清除的動作超前寫入的動作時,此時消費者在讀status時,不就會誤認資料已經寫完,以致於讀到舊的資料。

Rule4: 指(Col 2,Row 4),non-posted read是否可以超前posted write,答案是不行。就如同rule3一樣,如果把讀status的動作超前生產者的寫入動作,那麼消費者就無法得到從系統中得到正確的訊息,以致消費者就會發生錯誤。

Rule5: 指(Col 3,Row 1)或是(Col 4, Row 1),指posted write是否可以超non-posted read或是non-posted write。答案是可以的。不超前的話,會有死結產生。請看Fig,如果master1  發出一筆non-posted read到bridge , master3送出一筆non-posted read到bridge,當這兩筆同時被bridge Y接受時,因為兩邊bus都被佔住,所以無法執行這兩筆non-posted。之後master1又發出一筆posted write時,這一筆要能超前non-posted read,不然整個匯流排就會被這兩筆non-posted read卡住,而無法執行。如果posted write可以超前non-posted read,則就有可能等到所有的命令均被執行後,non-posted read才能有機會得到被執行的機會。

Rule6: 指(Col 3,Row 4),指剛剛發出的read,目的端已經回覆回來,是否可以超前non-posted read或是non-posted write。答案是可以的,因為既然正確的答案已經回傳回來,當然是要讓它儘快回到發送端,以便讓發送端再送出下一筆的命令。

Rule7: 指(Col 5,Row 1),是指posted write是否可以超前回覆的命令,答案是可以的。以生產者-消費者模型為例,如果data buffer和flag, status是不在相同的bus上,consumer發出一筆讀取status和flag的命令出來,在得到正確的訊息後,producer正要把資料寫入data buffer,所以這兩筆的資料都是正確的,沒有順序相依關係。所以超前是不會讓系統造成錯誤發生。

Others:其他的格子裏是寫Yes/No,是指超前可以,不超前也可以,要自己判斷。也就是說,如果命令間是沒有相關性的,那你就超前,如果有相關的,那你就不可以超前。這牽涉到系統規劃,以及和軟體間的溝通,所以沒有特別的答案,一切看自己。

 

其實,在這7個規則裏,都是因為存取動作的順序會造成資料的錯誤或是死結產生,所以才會特別告訴工程師,在遇到這些情況時,是可以超前,或是不可以超前。我沒有把會造成死結的情況詳細說明,這是因為,從Fig圖中,我們已經知道Bridge有三個,其中兩個是支援2.1版前的,另一個是支援2.1版的。因為版本的不同,造成命令在處理中,會有死結產生。

要詳細知道死結產生的情況,是要對 PCI 的規格了解。我怕有些人是不知道,所以用另一種方式來解答,是從命令上的意義來解答。如果想知道更周全的,建議詳讀 PCI 規格,就可以讓你能更了解為什麼要制定這些規則。

转载于:https://www.cnblogs.com/orchid123/p/3663367.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
The producer-consumer problem is a classic synchronization problem in computer science. It involves two processes, a producer and a consumer, who share a common buffer. The producer puts items into the buffer, while the consumer takes items out of the buffer. The problem arises when the buffer is full, and the producer needs to wait until the consumer has consumed some items before it can add more, and when the buffer is empty, and the consumer needs to wait until the producer has produced some items before it can consume them. One way to solve this problem is by using semaphores or locks. Semaphores are integer variables that can be used to control access to shared resources. They have two fundamental operations, wait() and signal(). The wait() operation decrements the semaphore value, and if it is negative, it blocks the process until the value becomes positive. The signal() operation increments the semaphore value and unblocks any waiting processes. A solution using semaphores for the producer-consumer problem involves two semaphores, empty and full, and a mutex lock. The empty semaphore is initialized to the size of the buffer, while the full semaphore is initialized to 0. The mutex lock is used to ensure that only one process can access the buffer at a time. The producer process waits on the empty semaphore, acquires the mutex lock, adds an item to the buffer, releases the mutex lock, and signals the full semaphore. The consumer process waits on the full semaphore, acquires the mutex lock, removes an item from the buffer, releases the mutex lock, and signals the empty semaphore. Here is some sample pseudocode: ``` // Shared variables int buffer[N]; int count = 0; // number of items in buffer int in = 0; // index for producer to put items int out = 0; // index for consumer to take items // Semaphores Semaphore empty = N; Semaphore full = 0; // Mutex lock Lock mutex; // Producer code while (true) { produce_item(); empty.wait(); mutex.acquire(); buffer[in] = item; in = (in + 1) % N; count++; mutex.release(); full.signal(); } // Consumer code while (true) { full.wait(); mutex.acquire(); item = buffer[out]; out = (out + 1) % N; count--; mutex.release(); empty.signal(); consume_item(item); } ``` This solution ensures that the producer and consumer processes do not access the buffer at the same time, and that the buffer is not overfilled or underfilled.

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值