TR202021690A1 - One-directional asynchronous communication system and method with crash recovery semantics - Google Patents

One-directional asynchronous communication system and method with crash recovery semantics

Info

Publication number
TR202021690A1
TR202021690A1 TR2020/21690A TR202021690A TR202021690A1 TR 202021690 A1 TR202021690 A1 TR 202021690A1 TR 2020/21690 A TR2020/21690 A TR 2020/21690A TR 202021690 A TR202021690 A TR 202021690A TR 202021690 A1 TR202021690 A1 TR 202021690A1
Authority
TR
Turkey
Prior art keywords
consumer
producer
message
units
buffer
Prior art date
Application number
TR2020/21690A
Other languages
Turkish (tr)
Inventor
Can Mustafa
Sezgi̇n Ali̇
Akyildiz Alper
Çulcu Erdem
Original Assignee
Aselsan Elektroni̇k Sanayi̇ Ve Ti̇caret Anoni̇m Şi̇rketi̇
Aselsan Elektronik Sanayi Ve Ticaret As
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aselsan Elektroni̇k Sanayi̇ Ve Ti̇caret Anoni̇m Şi̇rketi̇, Aselsan Elektronik Sanayi Ve Ticaret As filed Critical Aselsan Elektroni̇k Sanayi̇ Ve Ti̇caret Anoni̇m Şi̇rketi̇
Priority to TR2020/21690A priority Critical patent/TR202021690A1/en
Priority to PCT/TR2021/051175 priority patent/WO2022139733A1/en
Publication of TR202021690A1 publication Critical patent/TR202021690A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/548Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Systems (AREA)
  • Multi Processors (AREA)

Abstract

Buluş, iki birim arasında tek yönlü asenkron iletişim için çöküşten kurtarma semantiği içeren ve bayat veri tespiti yapabilen eksiksiz bir protokol önermektedir. Hem üretici hem de tüketici, her iki birim tarafından bilinen bellek bölgelerini okur ve buralara yazar. Birimler arasında mantıksal olarak paylaşılan bellek, fiziksel olarak paylaşılabilir veya PCIe veri yolu veya VME veri yolu gibi bir haberleşme ortamı aracılığıyla bağlanabilir. Kilitlenme, her iki birim tarafından atomik kilitler kullanılmadığından doğal olarak önlenir. Veri bütünlüğü, her iki birim tarafından da güncellenebilen bir bellek konumu olmamasıyla sağlanır. Veri geçerliliği, her iki birim tarafından da erişilebilen bir saatin kullanılmasıyla sağlanır. Çöküşten kurtarma, ortak bir saati kullanan el sıkışma yöntemi ile gerçekleştirilir.The invention proposes a complete protocol for one-way asynchronous communication between two units, including crash recovery semantics and capable of detecting stale data. Both the producer and the consumer read and write memory regions known to both units. Memory that is logically shared between units can be physically shared or connected via a communication medium such as a PCIe bus or VME bus. Deadlock is naturally avoided as atomic locks are not used by both units. Data integrity is ensured by the absence of a memory location that can be updated by both volumes. Data validity is ensured by the use of a clock that is accessible by both units. Recovery from collapse is accomplished by the handshake method, which uses a common clock.

Description

TARIFNAME ÇÖKÜSTEN KURTARMA SEMANTIKLI TEK YÖNLÜ ASENKRON ILETISIM SISTEMI VE METODU Teknik Alan Mevcut bulus, ayni fiziksel bellegi paylasma zorunlulugu olmayan iki birim arasinda tek yönlü asenkron iletisim ile ilgilidir. Bulusta kullanilan yöntem ile birimlerden herhangi birisi çöküsten kurtarildiktan sonra iletisim devam eder ve kurtarilmadan önce alinan veriler geçersiz hale getirilir. Teknigin Bilinen Durumu Proses, üzerinde çalistigi CPU'daki bir hesaplama çerçevesini kullanmak için isletim sistemi tarafindan saglanan bir soyutlamadir. Hesaplama çerçevesi, isletim sistemi tarafindan yönetilen ve prosesin erismesine izin verilen kaynaklari ifade eder. Adres uzayinin alt kümelerinin proseslerin kullanimlarina sunulmasi, isletim sistemi tarafindan saglanan tipik bir hizmettir. Ihtiyaç duyuldugunda isletim sistemi farkli proseslerin veri paylasabilmeleri için prosesler arasi iletisim hizmetleri de saglar. Prosesler arasi iletisim için kullanilan baslica yöntemlerden birisi farkli proseslerin erisebildigi paylasilan bellek kullanmaktir. Paylasilan bellek alanlarina, proseslerin siradan bellege ulasir gibi ulasmalarini andiran, görünürdeki basitlige ragmen özünde tekil olan bir nesneye ayni anda yapilan erisimlerdeki senkronizasyon zorluklari, kesfetmesi zor tasarim hatalarina yol açar. Senkronizasyon sorunlari için tipik bir çözüm, paylasilan bellek erisimlerini kritik bölümler olarak tanimlamak ve herhangi bir zamanda en fazla bir prosesin kritik bölümde olmasini saglamaktir. Isletim sistemleri, eszamanli erisim problemlerini çözmek için proseslere senkronizasyon mekanizmalari (muteks, semafor vb.) saglar. Prosesler ayrica, zaman damgali mesajlar gibi kilitleme mekanizmalarina gerek duymayan daha karmasik senkronizasyon algoritmalarini kullanabilir. Ayrica haberlesen prosesler arasindaki veri akis yöntemini kategorize etmek de mümkündür. Üretici -tüketici örüntüsü iki proses arasinda iletisim için kullanilan iyi bilinen yöntemlerde birisidir. Üretici -tüketici örüntüsünde, islenecek verinin üretilmesinden üretici sorumludur. Tüketici olarak adlandirilan diger proses, üretici tarafindan üretilen verinin tüketilmesinden sorumludur. Bu iletisim örüntüleri, yalnizca proseslerin bilgi üzerindeki erisimleri ile ilgilidir ve iletisim biçiminden (paylasilan bellek veya mesaj iletimi) bagimsizdir. degisim adi verilen islemciler arasi iletisim yaklasimi sunar. Bu gibi örüntülerde, iki islemci mesaj alisverisinde bulunur, ardindan bir hesaplama yapar ve ardindan bu islem tekrarlanir. Iki set gönderme ve alma tamponunun kullanilmasi halinde, alici tarafinda mesaji almak için her zaman bir alma tamponunun olmasini garanti etmek mümkündür. Bir mesaj iletme sistemi, hangi tamponlarin gönderme ve alma için kullanildigini kontrol eder. Bu tamponlar önceden tahsis edilir, böylece mesajlarin gönderildigi anda tekrarlanan bellek alimlarindan kaçinilmis olur. Gönderen, ilk olarak alicinin kullanacagi tüm olasi alma tamponlarindan haberdar edilir ve daha sonra bu alma tamponlari gönderen tarafindan dönüsümlü olarak üretilmis/ alinmis bayat verilerin tespitini yapma kabiliyetine sahip degildir. U89569291Bi numarali patent, ilk prosesin paylasilan bellege mesajlari yazmasi, bir mesajin yaziminin tamamlandiginin anlasilmasi, yazma isleminin tamamlanmasina cevap olarak paylasilan bellekteki bir noktaya karsilik gelen kayiklik degerinin ikinci prosese gönderilmesi, ikinci prosesin gönderilen kayikliga karsilik gelen bellek noktasindan önceki bir paylasilan bellek parçasinda tutulan bir veya daha fazla mesajin okunmasi ile ilgili prosesler arasi mesajlasma metotlari ve sistemleri ile ilgilidir. Ayrica, ikinci proses, kayiklik degerinden önceki paylasilan bellegin bir bölümünde bulunan tamponlarda saklanan bir veya daha fazla mesaji okur ve Okunanlari isler. Bu patent, islemciler arasinda mesajlasma sirasinda tampona yazilan mesajin, alici islemci tarafindan okunmadan ayni tampon üzerine baska islemciler tarafindan yazilamamasi açisindan bulusumuzla benzerlikler tasimaktadir. Bununla birlikte, bulusun CPU"lar arasi birimleri desteklemesi ve diger birimin bellegine yalnizca yazma erisimlerini gerektirmesi açisindan yukarida açiklanan patentten farklidir. Ayrica, U89569291B1 basvurusu herhangi bir çöküsten kurtarma semantigi saglamamasi bakimindan da basvuru konusu bulusumuzdan farklidir. Bulusun Kisa Açiklamasi Iki birim arasinda tek yönlü bir asenkron iletisim protokolünün gerçeklenmesi, kilitlenme önleme, veri bütünlügünü saglama ve verimli çalisma gibi iyi bilinen birçok problemi içinde barindirmaktadir. Protokol, çöküsten kurtarilma semantikleri gerektiriyorsa ve çöküsten önceki veriler geçersiz hale geliyorsa daha da karmasik hale gelir. Olasi gerçeklemeler tipik olarak, POSIX soketleri gibi daha alt seviyedeki proseslerin servislerini (örnegin isletim sistemi), kullanilan CPU'nun lSA'sinda karsiligi olan ya da olmayan atomik oku-degistir-yaz islemlerini kullanir. Çalismakta olan kodunun belirli bölümlerinin programci için seffafoldugu bu tip uygulamalar, emniyet kritik sistemlerde istenmez. Ek olarak, genel geçer çözümler, altta yatan mimarinin özelliklerinden yararlanamaz ve optimumun altinda performansa yol Bulus ayni veya farkli CPU'lar üzerinde bulunan bir üretici birim ve birtüketici birim arasinda baglanti kurar. Taraflardan her biri, diger tarafla iletisim kurmaya hazir oldugunda, birkaç teyitlesme verisi gönderir ve alir. Her iki taraf da digerinin varligini teyit ettikten sonra aralarinda haberlesme baslar. Soyut bir seviyede, üretici paylasilan çevrel bir tampona mesajlari ekler ve tüketici de ayni tampondan mesajlari okur. Paylasilan tamponun nasil gerçeklendigi, iki birimin ayni CPU'da mi (paylasilan bellekte bir bölge) yoksa farkli CPU'larda mi (farkli fiziksel cihazlarda bulunan iki bellek bölgesi) bulunduguna baglidir. Bulus tüketici tarafindan okunan mesajin bütünlügünü korumak için yükü saran kontrol verilerini kullanir. Kontrol verileri, her biri sadece proseslerden biri tarafindan güncellenebilen çesitli alanlari içerir. Bu ayni zamanda hem üreticinin hem de tüketicinin ilave kilit kullanmadan senkronize olmasini saglar. Bulus, üretici ve tüketici birimlerin ayri ayri erisebildigi bir üreteç tarafindan üretilen esit olarak artan bir deger dizisinin varligina dayanmaktadir. Bu bulus, hem üretici hem de tüketici tarafindan erisilebilen ortak bir sistem saatini kullanir. Mesajlarin kontrol kisminda bulunan zaman damgalari, tüketicinin bir sonraki mesaji bekledigi mesaj yuvasindaki verinin tüketilme kararini dogru olarak vermesine olanak saglar. Son olarak, çöküsten kurtarma semantigini saglamak için, teyitlesme veya iletisim sirasinda taraflardan biri veya her ikisi de çökerse, çöken tarafin yeniden baslatilmasindan sonra hizli bir teyitlesme ile iletisim yeniden kurulur. Bulus, ayni zamanda taraflardan birinin diger tarafin çöktügü ve kurtarildigi süre içinde çökmedigi durumu da ele almaktadir. Çöken taraf üretici ise, tüketici bayat mesajlari kullanmaz; çöken taraf tüketici ise, üretici, tüketicinin operasyonel moda dönmesini saglayana kadar gereksiz yere tamponu doldurmaktan kaçinir. Çizimlerin Kisa Açiklamasi Sekil1, hem üreticinin hem de tüketicinin ayni CPU üzerinde bulundugu durum için sistem mimarisini göstermektedir. Sekil2, üreticinin ve tüketicinin farkli CPU'larin üzerinde bulundugu durum için sistem mimarisini göstermektedir. Sekil 3, hem tüketici hem de üretici tarafindan kullanilan kontrol ve mesaj tamponlarinin yapisini göstermektedir. Sekil 4, 5, 6, 7', 8 ve 9, üretici, tüketici, kontrol tamponlari ve mesaj tamponlarinin durumlarini ve durum geçislerini gösterir. CPU'Iar arasi iletisim için örnek bir teyitlesme senaryosunu gösterir. üreticinin baslatilmasindan sonra tamponlarin etkinlestirildigi bir senaryoyu göstermektedir. üretici ve tüketici tamponlarin asenkron aktivasyonu için bir teyitlesme senaryosunu gösterir. çökmüs birimin yeniden baslatilmasindan sonra hazir hale gelmesi için örnek bir yeniden teyitlesme senaryosu gösterir. Parça Referanslari Üretici Tüketici Paylasilan bellek bölgesi Haberlesme ortami Üretici CPU Üretici Üretici bellegi Üretici bellek bölgesi Tüketici CPU Tüketici Tüketici bellegi Tüketici bellek bölgesi Kontrol tamponu Mesaj yuvasi [0] Mesaj yuvasi [1] Mesaj yuvasi [2] Tüketici tarafindan olusturulan veriler Üretici tarafindan olusturulan veriler Tüketicinin baslama zamani Tüketicinin teyit zamani Tüketicinin teyit ettigi baslama zamani Üreticinin son baslama zamani Üreticinin baslama zamani Üreticinin teyit zamani Üreticinin teyit ettigi baslama zamani Geçerlilik alani-1 Gönderim zamani Mesaj boyutu Geçerlilik alani-2 Prolnit durumu ProStart durumu ProOper durumu Conlnit durumu ConStart durumu ConOper durumu ProCBuflnit durumu ProCBufOper durumu ConCBqunit durumu ConCBufOper durumu ProMBuflnit durumu ProMBufOper durumu ConMBuflnit durumu T1532 ConMBufOper durumu ConMBufSnap durumu Üretici baslama geçisi Tüketicinin baslangicini algilama geçisi Tüketici teyidi algilama geçisi Basarisiz gönderme geçisi Basarili gönderme geçisi Tüketici baslama geçisi Üretici baslangicini algilama geçisi Basarisiz alma geçisi Basarili alma geçisi Üretici kontrol tamponu aktivasyon geçisi Üretici kontrol tamponu basarisiz yazma geçisi Üretici kontrol tamponu basarili yazma geçisi Tüketici kontrol tamponu aktivasyon geçisi Tüketici kontrol tamponu basarisiz yazma geçisi Tüketici kontrol tamponu basarili yazma geçisi Üretici mesaj tamponu aktivasyon geçisi Üretici mesaj tamponu ilklendirme geçisi Üretici mesaj tamponu yazma geçisi Tüketici mesaj tamponu aktivasyon geçisi Tüketici mesaj tamponu ilklendirme geçisi Tüketici mesaji tamponu anlik görüntü hazirlama geçisi Tüketici mesaj tamponu basarili alma geçisi Tüketici mesaj tamponu basarisiz alma geçisi Detayli Açiklama Bulusun detaylari bu bölümde aciklanacaktir. Ilk olarak üreticinin, tüketicinin, kontrol tamponlarinin ve mesaj tamponlarinin durumlari, durum geçislerinin sartlari ve eylemleri açiklanmaktadir. Sonrasinda, iletisim mekanizmasini açiklamak için birkaç örnek senaryo açiklanmistir. Sekil 1, hem üreticinin hem de tüketicinin ayni CPU'da bulundugu durum için (bundan böyle CPU içi olarak anilacaktir) sistem mimarisini göstermektedir. Sistem, hem üretici (102) hem de tüketici (103) tarafindan erisilebilen bellek (104) içerir. Birimlerin her ikisi de ayni CPU (101) üzerinde çalisir. Prosesler arasindaki iletisim tek yönlüdür. Üretici (102) veriyi paylasilan bellek bölgesine (105) yazar ve tüketici (103) ayni paylasilan bellek bölgesinden (105) veriyi okur. Paylasilan bellek bölgesinin (105) yapisi Sekil 3'te açiklanmaktadir. Sekil 2, üreticinin (, muhtemelen farkli kartlar üzerinde bulundugu durum (bundan böyle CPU`Iar arasi olarak anilacaktir) için sistem mimarisini gösterir. Bilhassa üretici ( üzerinde çalismaktadir. Her CPU'nun (fiziksel olarak) ayri kendi bellegine (üretici bellegi, tüketici bellegi) (213, 223) sahip oldugu varsayilir. Her bellek, iletisim için kullanilacak bir bölge içerir. Üretici (212), üreticinin bellek bölgesi (214) üzerinde yazma ve okuma erisim haklarina sahiptir. Benzer sekilde, tüketici (222), tüketici bellek bölgesi (224) üzerinde yazma ve okuma erisim haklarina sahiptir. CPU'Iar arasi yapilandirmada, hiçbir birim (yani üretici ve tüketici) diger CPU'nun bellegine dogrudan erisemez. Üretici ve tüketicinin iletisim kurdugu ortam ayrica dikkate alinmalidir. Bu ortama haberlesme ortami (201) adi verilmektedir. Asagida verilen varsayimlari karsiladigi sürece, haberlesme ortaminin (201) gerçeklenmesinde herhangi bir teknolojik kisitlama yoktur. Haberlesme ortaminin gerçeklenmesi için Ethernet veya PCIe uygun seçeneklerdir. Bulus, haberlesme ortaminin (201) mesajlari sirayla ilettigini varsayar. Ayrica iletim sirasinda mesajlarin asla kaybolmayacagi veya bozulmayacagi varsayilir. Son olarak, haberlesme ortami (201) iki yönlü iletisime olanak saglar. Bilhassa, tüketici (222) de üreticiye (212) mesaj (kontrol) gönderebilmelidir. Bulus, haberlesme ortaminin muhtemel ilklendirme asamasini hesaba katar. Haberlesme ortami (201) uygun sekilde ilklendirilmedikçe, ne tüketicinin (222) ne de üreticinin (212) haberlesme ortami (201) üzerinden mesaj gönderip alamayacagi varsayilir. ilklendirme isleminin eszamanli olarak iki yönde olmasina gerek yoktur; yani bulus haberlesme ortaminin (201) belirli bir yönde (örnegin tüketiciden üreticiye) ilklendirilmesinin mümkün oldugu durumu da hesaba katar. Baska bir deyisle, bulusun dogru çalismasi, haberlesme ortaminin (201) her iki yönde ayni anda ilklendirilmesine bagli degildir. Örnegin, üretici (212) operasyonel olmadan veya haberlesme ortami (201) üretici (102) - tüketici yönünde ilklendirilmeden önce bile tüketicinin (222) kendi teyit asamasi mesajini göndermesi ve bunu üreticinin bellek bölgesine (214) yazmasi mümkündür. Haberlesme ortami (201) üretici -tüketici yönünde ilklendirildigi zaman PRO_ACTIVATE_BUF olayi tetiklenir, ters yönde ilklendirildigi zaman CON_ACTIVATE_BUF olayi tetiklenir, Sekil 3, hem tüketici hem de üretici tarafindan kullanilan kontrol ve mesaj tamponlarinin yapisini göstermektedir. Her birimin tek bir kontrol tamponu (301) ve önceden yapilandirilmis sayida mesaj yuvasina (302, 303 ve 304) sahip bir mesaj tamponu vardir. Sekil 3'te örnek olarak üç mesaj yuvasi gösterilmektedir. Mesaj tamponu, çevrel tampon olarak yönetilir. Üretici, üretici tarafindan yazilacak bir sonraki mesaj yuvasini tutan bir yazma indeksi (Writeldx) degiskenine sahiptir ve tüketici, tüketici tarafindan okunacak bir sonraki mesaj yuvasini tutan bir okuma indeksi (Readldx) degiskenine sahiptir. Bu indeksler, mesaj tamponunun sonuna geldikleri zaman sifira ayarlanir. CPU içi yapilandirmada, her iki birimin kontrol ve mesaj tamponlari bellekte çakisir. CPU'Iar arasi yapilandirmada, her birimin kendi kontrol ve mesaj tamponlari vardir. Kontrol tamponundaki (301) veri alanlari iki gruba ayrilabilir. Bir grup sadece tüketici tarafindan olusturulan ve güncellenen veriler (305), diger grup sadece üretici tarafindan olusturulan ve güncellenen verilerden (306) olusmaktadir. Tüketici tarafindan üretilen veri alanlari, tüketicinin baslama zamanini (311), üreticinin baslama zamanini onaylama zamanini (312), üreticinin onaylanan baslama zamanini (313) ve üreticinin son tespit edilen baslama zamanini (314) tutar. Üretici tarafindan olusturulan veri alanlari, üreticinin baslama zamanini (315), tüketicinin baslama zamanini onaylama zamanini (316), tüketicinin onaylanan baslama zamanini (317) ve tüketicinin son tespit edilen baslama zamanini (318) içerir. Üretici tarafindan olusturulan veriler (306) ve tüketici tarafindan olusturulan veriler (305) bundan böyle "teyit verileri" olarak anilacaktir. ve alt bilgi (325) içerir. Mesaj tamponunun boyutu, birimler arasinda degis tokus edilecek maksimum mesaj boyutuna göre önceden yapilandirilir. Mesaj tamponundaki üst bilgi ve alt bilgi, birer geçerlilik alani (321, 325) içerir. Üst bilgi ayrica verinin mesaj tamponuna yazilma zamanini (322) ve yükteki mesajin boyutunu (323) içerir. Üretici, tüketici, kontrol tamponlari ve mesaj tamponlarinin durumlari ve durum geçisleri Sekil 4, 5, 6, 7, 8 ve 9'de gösterilmektedir. Her durum bir daire ile temsil edilmektedir. Baslangiç durumu çift daire ile gösterilir. Oklar bir durumdan digerine geçisleri gösterir. Durum degisikligine yol açmayan bir geçis dairesel bir okla temsil edilir. Durum geçisleri üç sekilde tetiklenebilir: baska bir durum geçisi sirasinda gerçeklestirilen bir eylemin algilanmasi, birimin kontrol tamponundaki (301) bir degisikligin algilanmasi ve harici bir olayin algilanmasi. Harici olaylar, isletim sistemi, kullanici uygulamalari veya çevresel cihazlar gibi harici aktörler tarafindan gerçeklestirilir. Bu olaylar büyük harflerle yazilmistir. Sekil 4, üreticinin durumlarini ve durum geçislerini göstermektedir. Prolnit durumu (401), üreticinin baslangiç durumudur. Birimin çalismaya baslamasi veya bir çöküs sonrasinda kurtarma için yeniden baslamasi (örnegin START_PRODUCER olayi), ProStart durumuna (402) geçis nedenleridir. ProOper durumu (403), mesaj iletiminin meydana geldigi üreticinin operasyonel oldugu durumdur. TD geçisi START_PRODUCER olayi ile etkinlestirilir ve üreticiyi ProStart durumuna (402) geçirir. To geçisi ile üreticinin baslama zamani (315), ortak saatin degerine ayarlanir ve Üretici, tüketicinin çalismaya basladigini tüketicinin baslama zamani (311) ve tüketicinin son baslama zamani (318) teyit verilerini kullanarak algiladiginda Ti geçisini yürütür. Eger tüketicinin baslama zamani (311), tüketicinin son baslama zamani (318) degerinden büyükse, bu durum tüketicinin ya ilk kez ya da bir çöküsten kurtarma sonrasinda basladigi anlamina gelir. Tüketicinin çalismaya basladigi algilandiginda InitProMBuf olayi tetiklenir, üreticinin teyit zamani (316) ortak saatin degerine, tüketicinin son baslama zamani (318) ve üreticinin teyit ettigi baslama zamani (317) tüketicinin baslama zamani (311) degerine esitlenir. Eger üretici ProStart durumundayken (402) tüketicinin teyit ettigi baslama zamani (313), üreticinin baslama zamanina (315) esitse Tz geçisi yürütülür. Tüketicinin teyit ettigi baslama zamani (313) üreticinin baslama zamanina (315) esit oldugunda üretici son baslangicinin teyit edildigini algilar. T2 geçisi üreticiyi ProOper durumuna (403) geçirir. Üreticinin durumuna bagli olarak, "SEND_MSG" olayi tetiklendiginde, T3 ya da T4 geçislerinden biri yürütülür. Ne Ts ne de T4 üreticinin durumunu degistirmez. T3, tüketiciye teyit verilerini (yani, üretici tarafindan olusturulan veriler (306)) göndermek için WriteProCbuf olayini tetikler. Öte yandan, T4 hem teyit verilerini hem de üreticinin mesajini tüketiciye göndermek için WriteProCBuf ve WriteProMBuf olaylarini tetikler. Üretici operasyonel durumdayken, üreticinin kontrol ve mesaj tamponlari da operasyonel durumdadir. Bu sebepten dolayi, T4 geçisi her zaman kontrol ve mesaj tamponlarinin degerlerini basariyla gönderebilir. Ancak üretici ProStart durumundayken (402), üreticinin kontrol tamponu (301) operasyonel olmayabilir. Bundan dolayi Ts geçisi teyit verilerini gönderemeyebilir. Sekil 5, üreticininkine çok benzeyen tüketicinin durumlarini ve durum geçislerini göstermektedir. Tüketicinin çalismaya baslamasi veya bir çöküs sonrasinda kurtarma için yeniden baslatilmasi (START_CONSUMER olayi), ConStart durumuna (502) geçise sebep olur. ConOper durumu (503), tüketicinin operasyonel oldugu mesaj iletiminin gerçeklestigi T5 geçisi, START_CONSUMER olayi ile etkinlestirilir ve geçis, tüketiciyi ConStart durumuna (502) geçirir. Ts geçisinin baslamasiyla, tüketicinin baslama zamani (311) ortak saatin degerine ayarlanir ve lnitConMBuf ve WriteConCBuf olaylari tetiklenir. Ts islemi, üreticinin baslama zamani (315) ve üreticinin son baslama zamani (314) teyit verileri kullanilarak üreticinin basladiginin tespit edilmesiyle gerçeklestirilir. Eger üreticinin baslama zamani (315), üreticinin son baslama zamani (314) degerinden büyükse, üreticinin ya ilk kez ya da bir çöküsten kurtarildiktan sonra basladigi anlamina gelir. Üreticinin çalismaya basladigi tespit edildikten sonra, lnitConMBuf olayi tetiklenir. Ayrica tüketicinin teyit zamani (312) ortak saatin degerine, üreticinin son baslama zamani (314) ve tüketicinin teyit ettigi baslama zamani (313) üreticinin baslama zamani (315) degerine esitlenir. Eger tüketici ConStart durumundayken (502) üreticinin teyit ettigi baslama zamani (317), tüketicinin baslama zamanina (311) esitse T7 geçisi yürütülür. Üreticinin teyit ettigi baslama zamani (317), tüketicinin baslama zamanina (311) esit oldugunda, tüketici son baslangicinin teyit edildigini algilar. T7 geçisi üreticiyi ConOper durumuna (503) geçirir. Tüketicinin durumuna bagli olarak, "RECV_MSG" olayi tetiklendiginde, Ts ya da Tg geçislerinden biri yürütülür. Ne Ts ne de Tg tüketicinin durumunu degistirmez. Ta, üreticiye teyit verilerini (yani tüketici tarafindan olusturulan veriler (305)) göndermek için WriteConCBuf olayini tetikler. Öte yandan, Tg hem teyit verilerini göndermek hem de üreticinin mesajini almak için WriteConCBuf ve ReadConMBuf olaylarini tetikler. Tüketici ConOper (503) durumundayken, tüketicinin kontrol ve mesaj tamponlari da operasyonel durumdadir. Bu sebepten dolayi, Tg geçisi her zaman kontrol tamponunun degerlerini gönderebilir ve her zaman (eger varsa) basariyla mesaj alabilir. Ancak tüketici ConStart durumundayken (502), tüketicinin kontrol tamponu (301) operasyonel olmayabilir. Bu sebepten dolayi, Ts geçisi teyit verilerini gönderemeyebilir. Sekil 6 ve Sekil 7', her iki birimin kontrol tamponlarinin durumlarini ve durum geçislerini göstermektedir. Kontrol tamponlari (301), birimler arasinda teyit verileri göndermek için Kullanilir. Üreticinin kontrol tamponunun (301) baslangiç durumu ProCBuflnit durumu (601) ve tüketicinin kontrol tamponunun baslangiç durumu ConCBqunit durumudur (701). Haberlesme ortami (201) bir yönde (örnegin üreticiden tüketiciye) veri göndermek için hazir oldugunda (örnegin PRO_ACTIVATE_BUF olayi tetiklendiginde), gönderici tarafin teyit verilerini tutan kontrol tamponu (301) operasyonel duruma geçer. Örnegin, haberlesme ortami (201) üretici - tüketici yönünde Tm geçisi ile ilklendirildiginde, üreticinin kontrol tamponu (301) ProCBufOper durumuna (602) geçer. Benzer sekilde haberlesme ortami (201) Tis geçisi ile tüketici - üretici yönünde ilklendirildiginde tüketicinin kontrol tamponu ConCBufOper durumuna (702) geçer. Üretici kontrol tamponu ProCBuflnit durumundayken (601) WriteProCBuf olayi tetiklenirse TH geçisi yürütülür. Üretici kontrol tamponu ProCBufOper durumundayken (602) WriteProCBuf olayi tetiklenirse T12 geçisi yürütülür. T12 geçisi sirasinda, üreticinin üretici tarafindan olusturulan verileri (306), haberlesme ortami (201) araciligiyla tüketicinin kontrol tamponundaki üretici tarafindan olusturulan veriler (306) bölümüne yazilir. Benzer sekilde, tüketici kontrol tamponu ConCBuflnit durumundayken (701) WriteConCBuf olayi tetiklenirse T14 geçisi yürütülür. Tüketici kontrol tamponu ConCBufOper durumundayken (702) WriteConCBuf olayi tetiklenirse Tis geçisi yürütülür. T15 geçisi sirasinda, tüketicinin tüketici tarafindan olusturulan verileri (305), haberlesme ortami (201) araciligiyla üreticinin kontrol tamponundaki tüketici tarafindan olusturulan veriler (305) bölümüne yazilir. Sekil 8, üreticinin mesaj tamponunun durumlarini ve durum geçislerini göstermektedir. Üreticinin mesaj tamponunun ilk durumu ProMBuflnit durumudur (801). Haberlesme ortami (201) üretici - tüketici yönünde ilklendirildiginde (yani PRO_ACTIVATE_BUF olayi tetiklendiginde), üretici mesaj tamponu Tm geçisi ile ProMBufOper durumuna (802) geçer. lnitProMBuf olayi tetiklendiginde T17 geçisi yürütülür. Geçis sirasinda, Wrideldx sifir a esitlenir ve üreticinin mesaj yuvalarinin geçerlilik alanlari (321, 325) geçersiz kilinir. WriteProMBuf olayi tetiklendigi sirada Writeldx indeksindeki mesaj yuvasinin geçerlilik alani-1 (321) geçersiz ise T1541, geçisi gerçeklesir. T1g'i tetikleyen mesaj yuvasinin geçerlilik (325) geçis sirasinda güncellenir. Gönderim zamani (322) ortak saatin degerine, mesaj boyutu (323) mesajin boyutuna esitlenir, yüke (324) mesajin içerigi yazilir ve geçerlilik alanlari (321, 325) geçerli olarak ayarlanir. Eger yapilandirma CPUllar arasi ise, mesaj yuvasi haberlesme ortami (201) tarafindan tüketicinin karsilik gelen mesaj yuvasina aktarilir. Mesaj yuvasinin iletilmesinden sonra, Writeldx, sonraki mesaj yuvasina isaret edecek sekilde artirilir. Sekil 9, tüketicinin mesaj tamponunun durumlarini ve durum geçislerini göstermektedir. Tüketicinin mesaj tamponunun iIk durumu ConMBqunit durumudur (901). Haberlesme ortami (201) tüketici - üretici yönünde hazir oldugunda (yani CON_ACTIVATE_BUF olayi tetiklendiginde), tüketici mesaj tamponu T19 geçisi ile ConMBufOper (902) durumuna geçer. endeksine ayarlanir ve tüketicinin bütün mesaj yuvalarinin geçerlilik alanlari (321, 325) geçersiz kiIinir. ReadConMBuf olayi tetiklendiginde (T21 geçisi sirasinda), Readldx dizinindeki mesaj yuvasinin içerigi tüketicinin bellegindeki bir yerel bellek bölgesine kopyalanir. T21geçisinden sonra, tüketicinin mesaj tamponu ConMBufSnap durumuna (903) geçer. Bayatlik ve bütünlük kontrolleri, kontrollerin gerçeklestirildigi zaman ile yükün geri döndürüldügü zaman arasinda verinin degistirilmediginden emin olmak için yerel bellek kopyasi üzerinde gerçeklestirilir. Mesajin bayatligini kontrol etmek için mesajin gönderim zamani (322), üreticinin teyit zamani (316), üreticinin baslama zamani (315) ve tüketicinin baslama zamani (311) ile karsilastirilir. Mesajin gönderim zamani (322) belirtilen veri alanlarinin hepsinden büyük veya esitse, yük hem tüketici hem de üretici operasyonel durumdayken üretilmistir, bu da verilerin bayat olmadigi anlamina gelir. Mesajin bütünlügünü kontrol etmek için geçerlilik alani-1 (321 ) ve geçerlilik alani-2 (325) alanlarinin geçerli veriye sahip olduguna ve birbirlerine esit olduguna bakilir. Bu kontrol CPU'Iar arasi yapilandirma için, mesajin tüketicinin yerel bellek alanina kopyalanmadan önce haberlesme ortami (201) tarafindan mesaj yuvasina iletildiginden emin olunmasini saglar. CPU içi yapilandirma için, mesajin tüketicinin yerel bellek alanina kopyalanmadan önce üretici tarafindan mesaj yuvasina yazildigindan emin olunmasini saglar. Mesajin yerel kopyasi, T22 geçisi ile birlikte bayatlik ve bütünlük kontrollerini geçerse, tüketicinin mesaj tamponu ConMBufOper (902) durumuna geçer ve RECV_MSG olayinin sonucu olarak yük döndürülür. T22 geçisinden sonra, tüketicinin ve üreticinin Readldx'teki mesaj yuvasindaki geçerlilik alanlari (321, 325) geçersiz kilinir ve ardindan Readldx bir sonraki mesaj yuvasini isaret edecek sekilde artirilir. Geçerlilik ve bütünlük kontrollerinden herhangi biri basarisiz olursa, tüketicinin mesaj tamponu T23 geçisi ile ConMBufOper durumuna (902) geçer. Örnek bir senaryo Sekil 10'da gösterilmektedir. Bu senaryoda haberlesme ortami (201) es zamanli olarak her iki yönde (yani üreticiden tüketiciye ve tüketiciden üreticiye) ilklendirilir ve PRO_ACTIVATE_BUF ve CON_ACTIVATE_BUF olaylari tetiklenir. Bu olaylarin sonucunda, üreticinin kontrol tamponu için T10 geçisi, üreticinin mesaj tamponu için T1a geçisi, tüketicinin kontrol tamponu için T13 geçisi ve tüketicinin mesaj tamponu için T19 geçisi, üretici ve tüketicinin baslamasindan önce gerçeklestirilir. Bu geçislerden sonra, her iki birimin her iki tamponu da (kontrol ve mesaj tamponlari) operasyonel duruma geçer. START_PRODUCER olayi ile To geçisi gerçeklestirilir. To geçisini, üreticinin mesaj tamponunu ilklendiren T17 geçisi ve üreticinin üretici tarafindan olusturulan verilerini (306) tüketicinin üretici tarafindan olusturulan verilerine yazari T12 geçisi izler. START_CONSUMER olayi ile T5 geçisi gerçeklestirilir. T5 geçisini, tüketicinin mesaj tamponunu ilklendiren T20 geçisi ve tüketicinin tüketici tarafindan olusturulan verilerini (305) üreticinin tüketici tarafindan olusturulan verilerine yazan T15 geçisi izler. T12 geçisinin sonucu olarak tüketici, üreticinin baslama zamaninin (315) üreticinin son baslama zamanindan (314) daha büyük oldugunu tespit eder ve Ts geçisini yürüterek tüketicinin teyit zamani (312), tüketicinin teyit ettigi baslama zamani (313) ve üreticinin son baslama zamani (314) alanlarini günceller. T5 geçisiyle birlikte tüketicinin tüketici tarafindan olusturulan verileri (305) gönderildiginde, üretici, tüketicinin baslama zamaninin (311) tüketicinin son baslama zamanindan (318) daha büyük oldugunu tespit eder ve üreticiyi operasyonel duruma geçiren T1 geçisi yürütülür. Bu noktada, her iki birim de operasyonel durumdadir (403, 503). SEND_MSG olayi ile T4 geçisi gerçeklestirilir. Üreticinin üretici tarafindan olusturulan verileri (306) T12 geçisi ile tüketici kontrol tamponunda (301) ilgili bölüme yazilir. Ardindan Tia geçisi tetiklenir ve üreticinin mesaj yuvasi tüketicinin ilgili mesaj yuvasina yazilir. tüketicinin tüketici tarafindan olusturulan verilerini (305) üreticiye aktaran WriteConCBuf olayini ve mesaj yuvasini tüketicinin yerel bellek bölgesine kopyalayan T21 geçisi ile sonuçlanan ReadConMBuf olayini tetikler. T22 geçisi yerel bellek bölgesindeki mesajin bütünlügünü ve bayatligini kontrol eder ve RECV_MSG olayinin sonucu olarak yükü (324) geri döndürür. Sekil 11, haberlesme ortaminin ilklendirilmesinin üretici ve tüketicinin baslama zamanlari arasinda yapildigi durum için örnek bir senaryo göstermektedir. Haberlesme ortami, üreticinin baslamasindan önce ilklendirilmedigi için, üreticinin kontrol tamponu ProCBuflnit durumunda (601) kalir ve üreticinin teyit verileri tüketiciye gönderilemez. Üreticinin kontrol tamponu ProCBuflnit (601) durumunda oldugu için, START_PRODUCER ve SEND_MSG olaylarindan sonra T12 geçisi yerine TH geçisi yürütülür. PRO_ACTIVATE_BUF olayi tetiklendigi zaman, T1o geçisi gerçeklestirilir ve üreticinin kontrol tamponu ProCBufOper durumuna (602) geçer. START_CONSUMER olayi ile T5 geçisi gerçeklestirilir. T5 geçisi, tüketicinin mesaj tamponunu ilklendiren T20 geçisini ve tüketicinin tüketici tarafindan olusturulan verilerini (305) üreticinin kontrol tamponundaki tüketici tarafindan olusturulan veriler bölgesine (305) yazan T15 geçisini tetikler. 'RECV_MSG' olayi, tüketicinin tüketici tarafindan üretilen verilerini (305) üreticiye aktaran T15 geçisiyle sonuçlanan WriteConCBuf olayini tetikleyen Ta geçisinin yürütülmesini tetikler. Bu noktada, her iki birim de operasyonel durumdadir (403, 503). SEND_MSG olayi ile T4 geçisi gerçeklestirilir. Üreticinin üretici tarafindan olusturulan verileri (306), T12 geçisi ile tüketicinin kontrol tamponundaki (301) ilgili bölüme yazilir. Bundan sonra Tm geçisi tetiklenir ve üreticinin mesaj yuvasi tüketicinin ilgili mesaj yuvasina yazilir. Tüketici üreticinin teyit verilerini (üreticinin teyit ettigi baslama zamani (317) ) aldiginda T7 geçisi ile ConOper durumuna (503) geçer. Bir sonraki "RECV_MSG" olayi ile tüketici, T9, T15. T21 ve T22 geçisleriyle ilk mesaj yuvasini okur ve geçersiz kilar. Sekil 12, bulusun dogru çalismasinin, haberlesme ortaminin (201) her iki yönde ayni anda ilklendirilmesine bagli olmadigini gösteren bir senaryoyu göstermektedir. PRO_ACTIVATE_BUF olayi, haberlesme ortamini (201) üretici - tüketici yönünde ilklendirdiginden dolayi, CON_ACTIVATE_BUF olayi haberlesme ortami (201) tarafindan tetiklenene kadar, tüketici üreticinin kontrol ve mesaj tamponlarina veri yazamayacaktir. Tüketici PRO_ACTIVATE_BUF ve CON_ACTIVATE_BUF olaylari arasindaki sürede ConOper durumuna (503) geçer. Fakat üretici ProOper durumuna (403) geçmek için tüketicinin teyit verilerini bekleyerek ProStart durumunda (402) kalir. Haberlesme ortami (201) tüketici - üretici yönünde ilklendirildikten sonra CON_ACTIVATE_BUF olayi tetiklenir. RECV_MSG olayi ile tüketicinin teyit verileri üreticinin kontrol tamponuna yazilir ve ProState durumunda (402) bekleyen üretici T2 geçisi ile ProOper durumuna (403) geçer. Tz geçisinden sonra, her iki birim de operasyonel durumdadir ve mesaj iletimi üretici üzerinde tetiklenen SEND_MSG ve tüketici üzerinde tetiklenen RECV_MSG olaylariyla devam eder. Sekil 13, hem birimler hem de birimlerin kontrol ve mesaj tamponlari operasyonel bir senaryoyu göstermektedir. Tüketicinin baslatilmasi T5, Bu ve T15 geçislerinin yürütülmesiyle sonuçlanan START_CONSUMER olayini tetikler. Tzo geçisi, tüketicinin mesaj tamponunu ilklendirir. T5 ve T15 geçisleri, teyit verilerini günceller ve ardindan bunlari üreticinin kontrol tamponuna yazar. T5 geçisi, tüketicinin ConStart durumuna (502) geçmesini saglar. Tüketiciden teyit verilerinin alinmasiyla, üretici T1 ve T17 geçislerini gerçeklestirir. T1 geçisi ile üreticinin üretici tarafindan üretilen verileri kontrol tamponunda güncellenir ve T17 geçisi üreticinin mesaj tamponunu ilklendirir. Sonraki SEND_MSG olayiyla birlikte, üreticinin kontrol tamponundaki teyit verileri ve gönderilecek mesaj T4, T12 ve Tig geçisleriyle tüketiciye yazilir. Tüketici, üreticiden teyit verilerini aldigi zaman T7 geçisi ile ConOper durumuna (503) geçer. Her iki birim de operasyonel (403, 503) olduktan sonra üretici yeniden baslatilirsa, yukarida tüketici için açiklanana benzer bir senkronizasyon isleminden sonra, her iki birim de operasyonel duruma geçer. TR TR TR TR TR DESCRIPTION ONE-WAY ASYNCHRONOUS COMMUNICATION SYSTEM AND METHOD WITH CRASH RECOVERY SEMANTIC Technical Field The present invention is related to one-way asynchronous communication between two units that do not have to share the same physical memory. With the method used in the invention, after any of the units is recovered from the crash, communication continues and the data received before recovery is invalidated. State of the Art A process is an abstraction provided by the operating system to use a computational framework in the CPU on which it runs. A computational framework refers to the resources managed by the operating system that the process is allowed to access. Making subsets of the address space available to processes is a typical service provided by the operating system. When needed, the operating system also provides inter-process communication services so that different processes can share data. One of the main methods used for inter-process communication is to use shared memory that different processes can access. Synchronization difficulties in simultaneous accesses to shared memory areas, similar to processes accessing ordinary memory, to an object that is essentially singular despite its apparent simplicity, lead to design errors that are difficult to discover. A typical solution for synchronization problems is to define shared memory accesses as critical sections and ensure that at most one process is in the critical section at any given time. Operating systems provide synchronization mechanisms (mutex, semaphore, etc.) to processes to solve concurrent access problems. Processes may also use more complex synchronization algorithms that do not require locking mechanisms such as timestamped messages. It is also possible to categorize the method of data flow between communicating processes. The producer-consumer pattern is one of the well-known methods used for communication between two processes. In the producer-consumer pattern, the producer is responsible for producing the data to be processed. The other process, called the consumer, is responsible for consuming the data produced by the producer. These communication patterns concern only the access of processes to information and are independent of the form of communication (shared memory or message transmission). It offers an interprocessor communication approach called exchange. In such patterns, two processors exchange messages, then perform a calculation, and then this process repeats. If two sets of send and receive buffers are used, it is possible to guarantee that there is always a receive buffer at the receiving end to receive the message. A message passing system controls which buffers are used for sending and receiving. These buffers are pre-allocated, thus avoiding repeated memory retrievals at the time messages are sent. The sender is first notified of all possible receive buffers that the receiver will use, and these receive buffers are then incapable of detecting stale data that has been alternately generated/received by the sender. The patent numbered U89569291Bi involves the first process writing messages to the shared memory, understanding that the writing of a message has been completed, sending the offset value corresponding to a point in the shared memory to the second process in response to the completion of the writing process, the second process using an or It is about inter-process messaging methods and systems related to reading more messages. Additionally, the second process reads one or more messages stored in buffers located in a portion of the shared memory before the offset value and processes the reads. This patent is similar to our invention in that the message written to the buffer during messaging between processors cannot be written by other processors on the same buffer without being read by the receiving processor. However, it differs from the patent described above in that the invention supports inter-CPU units and requires only write accesses to the memory of the other unit. Additionally, the U89569291B1 application differs from our subject invention in that it does not provide any crash recovery semantics. Brief Description of the Invention A one-way connection between two units Implementation of an asynchronous communication protocol has many well-known problems, such as deadlock prevention, data integrity, and efficiency. Possible implementations typically become more complex if the protocol requires crash recovery semantics and data before the crash becomes invalid, such as POSIX sockets. This type of applications, which use the services of lower-level processes (e.g. the operating system) and atomic read-modify-write operations that may or may not have a counterpart in the LSA of the CPU used, where certain parts of the running code are transparent to the programmer, are not desired in safety-critical systems. In addition, mainstream solutions cannot take advantage of the features of the underlying architecture and lead to sub-optimal performance. The invention connects a generating unit and a consuming unit located on the same or different CPUs. When each party is ready to communicate with the other party, it sends and receives several confirmation data. After both parties confirm the existence of the other, communication begins between them. At an abstract level, the producer adds messages to a shared peripheral buffer, and the consumer reads messages from the same buffer. How the shared buffer is implemented depends on whether the two units reside on the same CPU (one region in shared memory) or on different CPUs (two memory regions located in different physical devices). The invention uses control data surrounding the payload to maintain the integrity of the message read by the consumer. Control data contains several fields, each of which can only be updated by one of the processes. This also allows both the producer and the consumer to synchronize without using additional locks. The invention is based on the existence of an equally increasing series of values produced by a generator to which the producer and consumer units can access separately. This invention uses a common system clock that is accessible to both the manufacturer and the consumer. Timestamps in the control part of messages allow the consumer to make the correct decision to consume data in the message slot where he/she waits for the next message. Finally, to ensure crash recovery semantics, if one or both parties crash during assertion or communication, communication is re-established with a quick assertion after the crashed party restarts. The invention also addresses the situation where one of the sides collapses and does not collapse within the time the other side collapses and is rescued. If the producer is the one collapsing, the consumer will not use stale messages; If the crashed party is the consumer, the producer avoids unnecessarily filling the buffer until the consumer can return to operational mode. Brief Description of the Drawings Figure 1 shows the system architecture for the case where both the producer and the consumer are on the same CPU. Figure 2 shows the system architecture for the case where the producer and the consumer are on different CPUs. Figure 3 shows the structure of control and message buffers used by both the consumer and the producer. Figures 4, 5, 6, 7', 8, and 9 show the states and state transitions of the producer, consumer, control buffers, and message buffers. Shows an example verification scenario for inter-CPU communication. shows a scenario where buffers are enabled after the producer is initialized. shows a verification scenario for asynchronous activation of producer and consumer buffers. Shows an example reconfirmation scenario to get the crashed volume ready after rebooting. Part References Producer Consumer Shared memory region Communication medium Producer CPU Producer Producer memory Producer memory region Consumer CPU Consumer Consumer memory Consumer memory region Control buffer Message slot [0] Message slot [1] Message slot [2] Consumer created data Producer created data Consumer's start time Consumer's confirmation time Consumer's confirmed start time Producer's last start time Producer's start time Producer's confirmation time Producer's confirmed start time Validity area-1 Sending time Message size Validity area-2 Prolnit status ProStart status ProOper status Conlnit status ConStart status ConOper status ProCBuflnit state ProCBufOper state ConCBqunit state ConCBufOper state ProMBufOper state ConMBuflnit state T1532 ConMBufOper state ConMBufSnap state Producer start pass Consumer start detect pass Consumer confirmation detect pass Failed send pass Successful send pass Consumer start pass Producer start detect pass Failed receive pass Push aryl receive transition Manufacturer control buffer activation pass Producer control buffer failed write pass Producer control buffer successful write pass Consumer control buffer activation pass Consumer control buffer failed write pass Consumer control buffer successful write pass Producer message buffer activation pass Producer message buffer initialization pass Producer message buffer write pass Consumer message buffer activation pass Consumer message buffer initialization pass Consumer message buffer snapshot preparation pass Consumer message buffer successful receive pass Consumer message buffer failed receive pass Detailed Description The details of the invention will be explained in this section. First, the states of the producer, consumer, control buffers and message buffers, and the conditions and actions of state transitions are explained. Next, several example scenarios are described to explain the communication mechanism. Figure 1 shows the system architecture for the case where both the producer and the consumer are located on the same CPU (hereafter referred to as intra-CPU). The system includes memory 104 accessible by both the producer 102 and the consumer 103. Both units run on the same CPU (101). Communication between processes is one-way. The producer (102) writes the data to the shared memory region (105) and the consumer (103) reads the data from the same shared memory region (105). The structure of the shared memory region 105 is explained in Figure 3. Figure 2 shows the system architecture for the case where the manufacturer (hereafter referred to as Inter-CPU) is located, possibly on different boards. In particular, the manufacturer works on (. Each CPU has its own (physically) separate memory (producer memory, consumer memory). ) (213, 223). Each memory contains a region to be used for communication. Similarly, the producer (212) has write and read access rights to the producer's memory region (214). It has write and read access rights on (224). In the inter-CPU configuration, no unit (i.e. producer and consumer) can directly access the memory of the other CPU. The communication environment (201) in which the producer and consumer communicate should also be taken into account. As long as it meets the assumptions given below, there are no technological restrictions in the implementation of the communication environment (201). Ethernet or PCI are suitable options for the implementation of the communication environment. The invention assumes that the communication medium (201) transmits messages sequentially. It is also assumed that messages will never be lost or corrupted during transmission. Finally, the communication medium 201 allows two-way communication. In particular, the consumer 222 must also be able to send messages (control) to the producer 212. The invention takes into account the possible initialization phase of the communication medium. Unless the communication medium (201) is initialized appropriately, it is assumed that neither the consumer (222) nor the producer (212) will be able to send or receive messages over the communication medium (201). The initialization process does not need to be in both directions simultaneously; In other words, the invention also takes into account the situation where it is possible to initialize the communication environment (201) in a certain direction (for example, from consumer to producer). In other words, the correct operation of the invention does not depend on the communication medium (201) being initialized in both directions at the same time. For example, even before the producer (212) is operational or the communication environment (201) is initialized in the producer (102) - consumer direction, it is possible for the consumer (222) to send its own confirmation phase message and write it to the producer's memory area (214). When the communication medium (201) is initialized in the producer-consumer direction, the PRO_ACTIVATE_BUF event is triggered, and when it is initialized in the reverse direction, the CON_ACTIVATE_BUF event is triggered. Figure 3 shows the structure of the control and message buffers used by both the consumer and the producer. Each unit has a single control buffer (301) and a message buffer with a preconfigured number of message slots (302, 303, and 304). Figure 3 shows three message slots as examples. The message buffer is managed as a surround buffer. The producer has a write index (Writeldx) variable that holds the next message slot to be written by the producer, and the consumer has a read index (Readldx) variable that holds the next message slot to be read by the consumer. These indexes are set to zero when they reach the end of the message buffer. In the intra-CPU configuration, the control and message buffers of both units overlap in memory. In an inter-CPU configuration, each unit has its own control and message buffers. The data fields in the control buffer 301 can be divided into two groups. One group consists of data (305) created and updated only by the consumer, and the other group consists of data (306) created and updated only by the producer. Consumer generated data fields hold the consumer's start time (311), the producer's confirmed start time (312), the producer's confirmed start time (313), and the producer's last detected start time (314). Producer-generated data fields include the producer's start time 315 , the consumer's confirmed start time 316 , the consumer's confirmed start time 317 , and the consumer's last detected start time 318 . Producer-generated data 306 and consumer-generated data 305 are hereinafter referred to as "confirmation data". and includes footer (325). The size of the message buffer is preconfigured according to the maximum message size that will be exchanged between units. The header and footer in the message buffer each contain a validity field (321, 325). The header also includes the time the data was written to the message buffer (322) and the size of the message in the payload (323). The states and state transitions of the producer, consumer, control buffers and message buffers are shown in Figures 4, 5, 6, 7, 8 and 9. Each state is represented by a circle. The initial state is indicated by a double circle. Arrows indicate transitions from one state to another. A transition that does not lead to a change of state is represented by a circular arrow. State transitions can be triggered in three ways: detection of an action performed during another state transition, detection of a change in the unit's control buffer 301, and detection of an external event. External events are performed by external actors such as the operating system, user applications, or peripheral devices. These events are written in capital letters. Figure 4 shows the producer's states and state transitions. Prolnit state (401) is the initial state of the producer. The unit starting up or restarting for recovery after a crash (for example, the START_PRODUCER event) are causes for a transition to the ProStart state (402). ProOper state 403 is the operational state of the producer where message transmission occurs. The TD transition is activated by the START_PRODUCER event and puts the manufacturer into the ProStart state (402). With the To transition, the producer's start time (315) is set to the value of the common clock, and the Producer executes the Ti transition when it detects that the consumer has started using the confirmation data of the consumer's start time (311) and the consumer's last start time (318). If the consumer's start time 311 is greater than the consumer's last start time 318, this means that the consumer is starting either for the first time or after recovering from a crash. When the consumer is detected to start running, the InitProMBuf event is triggered, the producer's confirmation time (316) is set equal to the value of the common clock, the consumer's last start time (318) and the producer's confirmed start time (317) are set equal to the consumer's start time (311). If the consumer's confirmed start time (313) while the producer is in the ProStart state (402) is equal to the producer's start time (315), the transition Tz is executed. When the consumer's confirmed start time (313) is equal to the producer's start time (315), the producer detects that its last start has been confirmed. The T2 transition puts the producer into ProOper state (403). Depending on the state of the producer, when the "SEND_MSG" event is triggered, either T3 or T4 transitions are executed. Neither Ts nor T4 changes the producer's status. T3 triggers the WriteProCbuf event to send confirmation data (i.e., producer-generated data 306) to the consumer. On the other hand, T4 triggers the WriteProCBuf and WriteProMBuf events to send both the confirmation data and the producer's message to the consumer. When the producer is operational, the producer's control and message buffers are also operational. For this reason, the T4 relay can always successfully send the values of the control and message buffers. However, when the producer is in the ProStart state 402 , the producer's control buffer 301 may not be operational. Therefore, Ts relay may not be able to send confirmation data. Figure 5 shows the consumer's states and state transitions that are very similar to those of the producer. Starting the consumer or restarting it for recovery after a crash (START_CONSUMER event) causes a transition to ConStart state 502. ConOper state 503, the T5 transition where message transmission occurs when the consumer is operational, is activated by the START_CONSUMER event and the transition puts the consumer into ConStart state 502. With the start of the Ts transition, the consumer start time 311 is set to the value of the common clock and the LnitConMBuf and WriteConCBuf events are triggered. The Ts process is performed by detecting that the producer has started using the confirmation data of the producer's start time (315) and the producer's last start time (314). If the producer start time (315) is greater than the producer's last start time (314), it means that the producer started either for the first time or after recovering from a crash. Once the producer is detected to be running, the LnitConMBuf event is triggered. In addition, the consumer's confirmation time (312) is set equal to the value of the common clock, the producer's last start time (314) and the consumer's confirmed start time (313) are set equal to the producer's start time (315) value. If the producer's confirmed start time (317) while the consumer is in the ConStart state (502) is equal to the consumer's start time (311), the T7 transition is executed. When the producer's confirmed start time 317 is equal to the consumer's start time 311, the consumer detects that the final start has been confirmed. Transition T7 puts the generator into ConOper state (503). Depending on the state of the consumer, either Ts or Tg transitions are executed when the "RECV_MSG" event is triggered. Neither Ts nor Tg changes the consumer's state. Ta triggers the WriteConCBuf event to send confirmation data (i.e., consumer-generated data (305)) to the producer. On the other hand, Tg triggers the WriteConCBuf and ReadConMBuf events to both send confirmation data and receive the producer's message. When the consumer is in the ConOper (503) state, the consumer's control and message buffers are also operational. For this reason, the Tg relay can always send the values of the control buffer and can always successfully receive messages (if any). However, when the consumer is in the ConStart state 502 , the consumer's control buffer 301 may not be operational. For this reason, Ts relay may not be able to send confirmation data. Figure 6 and Figure 7 show the states and state transitions of the control buffers of both units. Control buffers (301) are used to send confirmation data between units. The initial state of the producer's control buffer (301) is the ProCBuflnit state (601) and the initial state of the consumer's control buffer is the ConCBqunit state (701). When the communication environment (201) is ready to send data in one direction (for example, from the producer to the consumer) (for example, when the PRO_ACTIVATE_BUF event is triggered), the control buffer (301) that holds the confirmation data of the sending party becomes operational. For example, when the communication medium (201) is initialized with a Tm transition in the producer-consumer direction, the producer's control buffer (301) switches to the ProCBufOper state (602). Similarly, when the communication medium (201) is initialized in the consumer-producer direction with the Tis transition, the consumer's control buffer switches to ConCBufOper state (702). If the WriteProCBuf event is triggered while the producer control buffer is in the ProCBuflnit state (601), the TH transition is executed. If the WriteProCBuf event is triggered while the producer control buffer is in the ProCBufOper state (602), the T12 transition is executed. During the T12 transition, the producer's producer-generated data (306) is written to the producer-created data (306) section in the consumer's control buffer via the communication medium (201). Similarly, if the WriteConCBuf event is triggered while the consumer control buffer is in the ConCBuflnit state (701), the T14 transition is executed. If the WriteConCBuf event is triggered while the consumer control buffer is in the ConCBufOper state (702), the Tis transition is executed. During the T15 transition, the consumer's consumer-generated data (305) is written to the consumer-generated data (305) section in the producer's control buffer via the communication medium (201). Figure 8 shows the states and state transitions of the producer's message buffer. The initial state of the producer's message buffer is the ProMBuflnit state (801). When the communication environment (201) is initialized in the producer-consumer direction (that is, when the PRO_ACTIVATE_BUF event is triggered), the producer message buffer switches to the ProMBufOper state (802) with the Tm transition. When the lnitProMBuf event is triggered, the T17 transition is executed. During the transition, Wrideldx is set to zero and the validity areas (321, 325) of the manufacturer's message slots are overridden. If the validity field-1 (321) of the message slot in the Writeldx index is invalid when the WriteProMBuf event is triggered, T1541 transition occurs. The validity 325 of the message slot that triggers T1g is updated during migration. The sending time (322) is set equal to the value of the common clock, the message size (323) is set equal to the size of the message, the content of the message is written to the payload (324), and the validity fields (321, 325) are set to valid. If the configuration is inter-CPU, the message slot is transferred to the corresponding message slot of the consumer by the communication medium (201). After the message slot is transmitted, Writeldx is incremented to point to the next message slot. Figure 9 shows the states and state transitions of the consumer's message buffer. The initial state of the consumer's message buffer is the ConMBqunit state (901). When the communication environment (201) is ready in the consumer - producer direction (that is, when the CON_ACTIVATE_BUF event is triggered), the consumer message buffer switches to the ConMBufOper (902) state with the T19 transition. index and the validity fields (321, 325) of all message slots of the consumer are invalidated. When the ReadConMBuf event is triggered (during the T21 transition), the contents of the message slot in the Readldx directory are copied to a local memory region in the consumer's memory. After transition T21, the consumer's message buffer transitions to ConMBufSnap state 903. Staleness and integrity checks are performed on the local memory copy to ensure that the data has not been modified between the time the checks are performed and the time the payload is returned. To check the staleness of the message, the message sending time (322) is compared with the producer's confirmation time (316), the producer's start time (315) and the consumer's start time (311). If the message sending time 322 is greater than or equal to all of the specified data fields, the payload was generated while both the consumer and the producer were operational, which means the data is not stale. To check the integrity of the message, it is checked that the validity area-1 (321) and validity area-2 (325) fields have valid data and are equal to each other. This control ensures that, for inter-CPU configuration, the message is transmitted to the message slot by the communication medium (201) before being copied to the consumer's local memory area. For in-CPU configuration, it ensures that the message is written to the message slot by the producer before being copied to the consumer's local memory space. If the local copy of the message passes the staleness and integrity checks with the T22 transition, the consumer's message buffer moves to the ConMBufOper (902) state and the payload is returned as a result of the RECV_MSG event. After the T22 transition, the validity fields 321, 325 of the consumer and producer in the message slot in Readldx are invalidated and Readldx is then incremented to point to the next message slot. If any of the validity and integrity checks fail, the consumer's message buffer transitions to ConMBufOper state 902 with transition T23. An example scenario is shown in Figure 10. In this scenario, the communication medium 201 is initialized simultaneously in both directions (i.e., from producer to consumer and from consumer to producer) and the PRO_ACTIVATE_BUF and CON_ACTIVATE_BUF events are triggered. As a result of these events, transition T10 for the producer's control buffer, transition T1a for the producer's message buffer, transition T13 for the consumer's control buffer, and transition T19 for the consumer's message buffer are performed before the producer and consumer start. After these transitions, both buffers of both units (control and message buffers) become operational. The To transition is performed with the START_PRODUCER event. The To pass is followed by pass T17, which initializes the producer's message buffer, and pass T12, which writes the producer's producer-generated data 306 to the consumer's producer-generated data. T5 transition is performed with the START_CONSUMER event. Transition T5 is followed by transition T20, which initializes the consumer's message buffer, and transition T15, which writes the consumer's consumer-generated data 305 to the producer's consumer-generated data. As a result of transition T12, the consumer detects that the producer's start time 315 is greater than the producer's last start time 314 and executes transition Ts, resulting in the consumer's confirmed start time 312, the consumer's confirmed start time 313, and the producer's last start time 314. ) updates the fields. When the consumer's consumer-generated data 305 is sent along with the T5 transition, the producer detects that the consumer's start time 311 is greater than the consumer's last start time 318 and the T1 transition is executed, which puts the producer into operational state. At this point, both units are operational (403, 503). T4 transition is performed with the SEND_MSG event. The producer's data (306) created by the producer is written to the relevant section in the consumer control buffer (301) with the T12 transition. Then the Tia transition is triggered and the producer's message slot is written to the consumer's corresponding message slot. triggers the WriteConCBuf event, which transfers the consumer's consumer-generated data 305 to the producer, and the ReadConMBuf event, which results in the T21 transition, which copies the message slot to the consumer's local memory region. The T22 relay checks the integrity and staleness of the message in the local memory area and returns payload 324 as a result of the RECV_MSG event. Figure 11 shows an example scenario where the initialization of the communication environment is done between the producer and consumer startup times. Since the communication medium is not initialized before the producer starts, the producer's control buffer remains in the ProCBuflnit state (601) and the producer's confirmation data cannot be sent to the consumer. Since the producer's control buffer is in the ProCBuflnit (601) state, the TH transition is executed instead of the T12 transition after the START_PRODUCER and SEND_MSG events. When the PRO_ACTIVATE_BUF event is triggered, the T10 transition occurs and the producer's control buffer moves to the ProCBufOper state (602). T5 transition is performed with the START_CONSUMER event. Transition T5 triggers transition T20, which initializes the consumer's message buffer, and transition T15, which writes the consumer's consumer-generated data 305 to the consumer-generated data region 305 in the producer's control buffer. The 'RECV_MSG' event triggers the execution of transition Ta, which triggers the WriteConCBuf event, resulting in transition T15, which transfers the consumer's consumer-generated data 305 to the producer. At this point, both units are operational (403, 503). T4 transition is performed with the SEND_MSG event. The producer's data (306) created by the producer is written to the relevant section in the consumer's control buffer (301) via the T12 transition. After this, the Tm transition is triggered and the producer's message slot is written to the consumer's corresponding message slot. When the consumer receives the manufacturer's confirmation data (the manufacturer's confirmed start time (317)), it moves to the ConOper state (503) with the T7 transition. Consumer with next "RECV_MSG" event, T9, T15. Reads and invalidates the first message slot with transitions T21 and T22. Figure 12 shows a scenario showing that the correct operation of the invention does not depend on the communication medium 201 being initialized in both directions simultaneously. Since the PRO_ACTIVATE_BUF event initializes the communication environment (201) in the producer - consumer direction, the consumer will not be able to write data to the producer's control and message buffers until the CON_ACTIVATE_BUF event is triggered by the communication environment (201). The consumer transitions to ConOper state 503 between the PRO_ACTIVATE_BUF and CON_ACTIVATE_BUF events. However, the producer remains in the ProStart state (402) waiting for the consumer's confirmation data to move to the ProOper state (403). After the communication environment (201) is initialized in the consumer - producer direction, the CON_ACTIVATE_BUF event is triggered. With the RECV_MSG event, the consumer's confirmation data is written to the producer's control buffer, and the producer waiting in the ProState state (402) moves to the ProOper state (403) with the T2 transition. After the Tz transition, both units are operational and message transmission continues with SEND_MSG events triggered on the producer and RECV_MSG events triggered on the consumer. Figure 13 shows an operational scenario with both units and their control and message buffers. Initialization of the consumer triggers the START_CONSUMER event, resulting in the execution of transitions T5, Bu, and T15. The Tzo relay initializes the consumer's message buffer. Transitions T5 and T15 update the confirmation data and then write them to the producer's control buffer. Transition T5 causes the consumer to enter ConStart state 502. Upon receipt of confirmation data from the consumer, the producer performs T1 and T17 transitions. With transition T1, the producer's data generated by the manufacturer is updated in the control buffer, and transition T17 initializes the manufacturer's message buffer. With the next SEND_MSG event, the confirmation data in the producer's control buffer and the message to be sent are written to the consumer with T4, T12 and Tig transitions. When the consumer receives confirmation data from the producer, it moves to ConOper state (503) with transition T7. If the generator is restarted after both units are operational (403, 503), after a synchronization process similar to that described above for the consumer, both units will become operational.TR TR TR TR TR

Claims (1)

1.ISTEMLER Çöküsten kurtarma semantigine sahip tek yönlü asenkron iletisim sistemi olup, özelligi; ayni veya farkli islemcilerde bulunan bir üretici ve bir tüketici, fiziksel olarak paylasilabilen veya birimlerin iletisim kurmalarini saglayan bir ortam yoluyla baglanabilen, birimlerin kendi bellek bölgelerine yazma ve okuma diger birimlerin bellek bölgelerine yazma hakkinin bulundugu, üretici ve tüketici birimler arasinda mantiksal olarak paylasilan bellek, zaman bilgisi içermesi zorunlu olmayan, monoton olarak artan ve ayni anda tüm birimlerden erisildiginde ayni degeri veren saat aygiti içermektedir. Çöküsten kurtarma semantigine sahip tek yönlü asenkron iletisim metodu olup, özelligi; ayni veya farkli islemcilerde bulunan üretici ve tüketici birimlerin, baslama zamanlarini birbirlerine göndermesi ve diger birimden baslama teyidi almamisken diger birimin birden çok kez yeniden baslayabilecegini hesaba katarak kendi baslamalari için teyit beklenmesi, bir birim diger birimin bellegine yazabilirken tersi yönde yazmanin mümkün olmamasina neden olan, haberlesme ortaminin farkli yönlerde (üreticiden tüketiciye ve tüketiciden üreticiye) ilklendirilmesinin asenkron olmasi, her bir birimin bagimsiz olarak kendi tampon durumunu idame ettirmesi ve tüketici mesaji okumadan önce hem üretici hem de tüketici mesaj tamponlarinda bu mesajin üzerine yazilmamasi, her bir birimin bagimsiz olarak kendi tampon durumunu idame ettirmesi ve tüketicinin (yeniden) baslamasi öncesinde alinan bayat mesajlarin yok sayilmasi, birimin baslama zamaninin birim basladiginda veya bir çöküsten kurtarildiginda sifirlandigi, her bir birimin sahipliginde olan kontrol tamponlarinda tutulan birimin son tespit edilen baslama zamani ve teyit gönderme zamaniyla birimlerin baslama ve teyit zamanlarinin takip edilmesi, her bir birimin sahip oldugu bir mesaj tamponundaki mesaj yuvalarinin, sabit boyutta yük bölümü ve bu bölümü saran iki kontrol bölümü içermesi ve bu kontrol bölümlerinden öndekinin mesajin gönderim zamanini, mesaj boyutunu ve geçerlilik verisini içerirken sondakinin sadece geçerlilik verisi içermesi, o bir birimin diger birimlerin bellek bölgelerine yalnizca yazma erisimi gerektirmesidir. Istem 2'ye göre metot olup, özelligi; tampondaki mevcut mesaj tüketici tarafindan okunana kadar üreticinin yeni bir mesaj yazmamasi ve tüm veriler henüz tampona kopyalanmamissa tüketicinin bu mesaji okumamasidir. Istem 2”ye göre metot olup, özelligi; tüketicinin mesaj yuvasinin içerigini yerel degiskenlerine kopyalamasi, bu yerel kontrol degiskenlerini kontrol etmesi ve eger her iki yerel geçerlilik degiskeni de geçerliyse, yerel yük alanini yeni bir mesaj olarak okumasidir. TR TR TR TR TR1. CLAIMS It is a one-way asynchronous communication system with crash recovery semantics, and its feature is; A producer and a consumer located on the same or different processors, which can be shared physically or connected through a medium that allows the units to communicate, where the units have the right to write and read to their own memory regions and to write to the memory regions of other units, memory that is logically shared between the producer and consumer units, time It contains a clock device that does not necessarily contain information, increases monotonically and gives the same value when accessed from all units at the same time. It is a one-way asynchronous communication method with crash recovery semantics, and its features are; Producer and consumer units located in the same or different processors send their start times to each other and wait for confirmation for their own start, taking into account that the other unit may restart more than once while not receiving a start confirmation from the other unit, which causes communication, while one unit can write to the memory of the other unit, it is not possible to write in the opposite direction. The initialization of the environment in different directions (producer to consumer and consumer to producer) is asynchronous, each unit independently maintains its own buffer state, and this message is not overwritten in both the producer and consumer message buffers before the consumer reads the message, each unit independently maintains its own buffer state. tracking the volume's startup and confirmation times, with the unit's last detected startup time and confirmation sending time held in control buffers owned by each unit, where the unit's startup time is reset when the unit starts up or recovers from a crash. , the message slots in a message buffer owned by each unit contain a fixed-size payload section and two control sections surrounding this section, and the front of these control sections contains the sending time of the message, message size and validity data, while the last one contains only validity data. This is because it requires write-only access to memory regions. It is a method according to claim 2 and its feature is; The producer does not write a new message until the current message in the buffer is read by the consumer, and the consumer does not read this message if all data has not yet been copied to the buffer. It is a method according to claim 2 and its feature is; is that the consumer copies the contents of the message slot into its local variables, checks those local control variables, and if both local validity variables are valid, reads the local payload slot as a new message. TR TR TR TR TR
TR2020/21690A 2020-12-25 2020-12-25 One-directional asynchronous communication system and method with crash recovery semantics TR202021690A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
TR2020/21690A TR202021690A1 (en) 2020-12-25 2020-12-25 One-directional asynchronous communication system and method with crash recovery semantics
PCT/TR2021/051175 WO2022139733A1 (en) 2020-12-25 2021-11-10 One-directional asynchronous communication system and method with crash recovery semantics

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
TR2020/21690A TR202021690A1 (en) 2020-12-25 2020-12-25 One-directional asynchronous communication system and method with crash recovery semantics

Publications (1)

Publication Number Publication Date
TR202021690A1 true TR202021690A1 (en) 2022-07-21

Family

ID=78827682

Family Applications (1)

Application Number Title Priority Date Filing Date
TR2020/21690A TR202021690A1 (en) 2020-12-25 2020-12-25 One-directional asynchronous communication system and method with crash recovery semantics

Country Status (2)

Country Link
TR (1) TR202021690A1 (en)
WO (1) WO2022139733A1 (en)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10178186B2 (en) * 2016-06-16 2019-01-08 Sap Se Connection reestablishment protocol for peer communication in distributed systems
CN109478139B (en) * 2016-08-13 2024-01-23 英特尔公司 Apparatus, method and system for access synchronization in shared memory

Also Published As

Publication number Publication date
WO2022139733A1 (en) 2022-06-30

Similar Documents

Publication Publication Date Title
US7145837B2 (en) Global recovery for time of day synchronization
US7668923B2 (en) Master-slave adapter
US4864496A (en) Bus adapter module for interconnecting busses in a multibus computer system
US4979097A (en) Method and apparatus for interconnecting busses in a multibus computer system
US20050091383A1 (en) Efficient zero copy transfer of messages between nodes in a data processing system
JP2644780B2 (en) Parallel computer with processing request function
US20050081080A1 (en) Error recovery for data processing systems transferring message packets through communications adapters
Jayanti et al. Recoverable FCFS mutual exclusion with wait-free recovery
JPH0656587B2 (en) Fault tolerant data processing system
US5271020A (en) Bus stretching protocol for handling invalid data
WO2007081661A2 (en) Method and system usable in sensor networks for handling memory faults
US20050080869A1 (en) Transferring message packets from a first node to a plurality of nodes in broadcast fashion via direct memory to memory transfer
US8943516B2 (en) Mechanism for optimized intra-die inter-nodelet messaging communication
US20050080920A1 (en) Interpartition control facility for processing commands that effectuate direct memory to memory information transfer
Mostéfaoui et al. Time-efficient read/write register in crash-prone asynchronous message-passing systems
US5386544A (en) Data processing system with a standby process mechanism for saving and restoring operations
Bonomi et al. Stabilizing server-based storage in Byzantine asynchronous message-passing systems
EP2845110B1 (en) Reflective memory bridge for external computing nodes
US20050080945A1 (en) Transferring message packets from data continued in disparate areas of source memory via preloading
Proenza et al. The design of the CANbids architecture
TR202021690A1 (en) One-directional asynchronous communication system and method with crash recovery semantics
CN110309224B (en) Data copying method and device
Michael et al. Recovering shared objects without stable storage
JPH1173365A (en) Method for optimizing data moving operation
Chen et al. A three-slot asynchronous reader/writer mechanism for multiprocessor real-time systems