Cooperative Scheduling mi ? Fixed Pre-emptive Scheduling mi?

[kageja]

Merhaba Arkadaslar,

Fixed Pre-emptive scheduling uzerine bir calisma yuruyorum. Ancak farkli scheduling metodlarina da illaki bakmak istedim maksat heyecan
Ancak gordumki Cooperative scheduling TinyOS ve Salvo gibi cok az RTOS'da kullaniliyormus?
Dogal olarak Round Robin Scheduling'de ayni sekilde cok az mi tervih ediliyor?

Sizler Projeleriniz nasil bir Scheduling Algoritmasi kullaniyorsunuz ? Size uygun olarak avantajlari dezavantajlari nelerdi ?

Saygilarimla iyi calismalar.

[Tagli]

Eski bir konuyu hortlatmış olacağım ama benzer bir konuda sorum var:

RTOS kullandığınız uygulamalarınızda ne tür bir scheduler tercih ediyorsunuz? Cooperative mi yoksa Preemptive mi?

Elbette preemptive olan, değişen durumlara ve olaylara daha hızlı tepki veriyor. Ancak önemli 2 eksisi var:
1) Daha sık görev değişimine (context switch) sebep olarak işlemciye daha fazla yük getiriyor.
2) Görevler arada kesilebildiği için, ortak veri paylaşımı durumunda mutex kullanmak gerekiyor. Bu da yine daha fazla işlemci yükü demek. Ek olarak öncelik ters dönmesi (priority inversion) denen soruna da sebep olabiliyor.

Acaba cooperative yöntemini kullanıp görevleri de mümkün olduğunca kısa sürede işlerini bitirecek şekilde tasarlarsak, mutex'lerden kurtularak programı daha rahat yazabilir ve daha az görev değişim yükü ile çalışır hale getirebilir miyiz? Bu yönde denemeleriniz oldu mu?

Bu arada, ben FreeRTOS kullanıyorum ve FreeRTOS iki yönteme de destek veriyor. Bugüne kadar preemptive kullandım hep ama projeler büyüdükçe senkronizasyon daha büyük sorun olmaya başlıyor gibi.

Bu arada bazı yaklaşımlara göre veriyi paylaşmak ve mutex kullanmak başlı başına bir tasarım hatası. Örneğin Miro Samek gibi uzmanlar işi bitene kadar çalışan (Run To Completion) ve birbiri ile event'ler ile iletişim kuran küçük iş parçacıkları öneriyor. Ancak bu tasarım yöntemi oldukça farklı bir düşünme şeklini gerektiriyor ve öyle bir anda geçilebilecek bir şey değil. Veri paylaşımı ve mutex kullanımını azaltmaya çalışsam da tamamen kaçınmayı başaramadım şimdiye kadar.

[Erol YILMAZ]

Bütün uygulamalar için tek bir yöntem olabilir mi?

Farklı ihtiyaçlara göre bu konu da şekillenmez mi?

[quarko]

İhtiyaçlar farklılaştıkça aynı çözümlerde ısrar etmemek lazım. Her projede rtos gerekmez. Ama insan alışınca en ufak işte bile rtos kullanmak istiyor. Ben rtos'un round robin çalışma şeklini daha çok seviyorum. Preemptive'in faydası var ama işleri karmaşıklaştırıyor. Cooperative Multitasking bile bazı işlerde fazla fazla yeterli geliyor.

Ben çoğunlukla message queue tabanlı event-driven bir sistem tercih ediyorum. Yoğun kesmelerin olduğu bir durumda cpu yu bir rtos a göre çok çok daha az yoruyor. Task scheduling için zaman kaybım yok. Mutex vs. kullanmama gerek kalmıyor. Çok daha basit ve etkili bir çözüm sunuyor.

[mr.engineer]

FreeRTOS hem preemptive hem de cooperative kullanmayı destekliyor mu? İkisini birlikte kullanmak işinizi görmüyor mu?

[Tagli]

İkisini de destekliyor ama aynı anda değil tabi. Ya birini, ya öbürünü seçmek gerekli. Seçime göre programı yazma şekli de bir miktar değişmeli. O yüzden olay sadece config dosyasında bir satırı değiştirmekten ibaret değil.

Ben soruyu genel olarak sordum, deneyimlerinizi duymak için. Yoksa çözmeye çalıştığım özel bir sorun yok.

[MrDarK]

Hocam selamlar,

@quarko 'nun yorumlarına katılmak ile birlikte eğer FreeRtos kullanımdan önceki kullandığın kodlama teknigi modüler, state machine task tabanlı, event flag drive şeklinde ise cooperative kullanmak oldukça kolay oluyor. Tabi erol hocanın dediği projeye göre çözüm konusu da önemli.

[Erol YILMAZ]

Ihtiyaçlarimizi karsilayabilecek primitive derecede basit, state machine tabanlı bir mantık kullaniyoruz.
Arada bir Rtos kullanmak istesek te, elimizde bizi 15 senedir hic yaniltmamış, her satirini özümsediğimiz bir altyapi olunca vazgeçtik.

Düşünüyorum aslında bu yaklasim bizi uğraştırıyor mu...?
Açıkçası task kodlarını oluşturmak projenin en zor taraflarindan birisi değil. Belki de en kolay tarafı.
Şu ana kadar Preemptive bir uygulamaya ihtiyacimiz olduğunu hatirlamiyorum.
Zaten task ta birkac durum kontrol edilip çıkılıyor.

Bir string'i transmit etmek için konuyu dma'e, interruptlari istediğimiz gibi kullanabilmeye ihtiyaç duyuyoruz. Kritik yapilar.

Tabi ki bunlar bizim ihtiyaçlarimiz için böyle, farkli uygulamalara binaen farkli ihtiyaçlar olacaktır.

Bence şu kritik soruyu sormalı...
Cooperative işletim, uygulama yapmamı engelliyor veya çok zorlaştiriyor mu?
Cevap hayır ise neden Preemptive isletime gectik?

Kendi bakış açımdan;
Hakimiyet hissedemediğim araçları kullanmak istemiyorum.

[yamak]

Eski bir konuyu hortlatmış olacağım ama benzer bir konuda sorum var:

RTOS kullandığınız uygulamalarınızda ne tür bir scheduler tercih ediyorsunuz? Cooperative mi yoksa Preemptive mi?

Elbette preemptive olan, değişen durumlara ve olaylara daha hızlı tepki veriyor. Ancak önemli 2 eksisi var:
1) Daha sık görev değişimine (context switch) sebep olarak işlemciye daha fazla yük getiriyor.
2) Görevler arada kesilebildiği için, ortak veri paylaşımı durumunda mutex kullanmak gerekiyor. Bu da yine daha fazla işlemci yükü demek. Ek olarak öncelik ters dönmesi (priority inversion) denen soruna da sebep olabiliyor.

Acaba cooperative yöntemini kullanıp görevleri de mümkün olduğunca kısa sürede işlerini bitirecek şekilde tasarlarsak, mutex'lerden kurtularak programı daha rahat yazabilir ve daha az görev değişim yükü ile çalışır hale getirebilir miyiz? Bu yönde denemeleriniz oldu mu?

Bu arada, ben FreeRTOS kullanıyorum ve FreeRTOS iki yönteme de destek veriyor. Bugüne kadar preemptive kullandım hep ama projeler büyüdükçe senkronizasyon daha büyük sorun olmaya başlıyor gibi.

Bu arada bazı yaklaşımlara göre veriyi paylaşmak ve mutex kullanmak başlı başına bir tasarım hatası. Örneğin Miro Samek gibi uzmanlar işi bitene kadar çalışan (Run To Completion) ve birbiri ile event'ler ile iletişim kuran küçük iş parçacıkları öneriyor. Ancak bu tasarım yöntemi oldukça farklı bir düşünme şeklini gerektiriyor ve öyle bir anda geçilebilecek bir şey değil. Veri paylaşımı ve mutex kullanımını azaltmaya çalışsam da tamamen kaçınmayı başaramadım şimdiye kadar.

Hocam bu tamamen isterler ile ilgili bir durum.
Eğer time critical bir sistemse priority based preemtive scheduler kullanmak gerekir. Ayrıca rtos'lardaki mutex'ler priority inheritance ile priority inversion'ı engelliyor.

[Tagli]

Ayrıca rtos'lardaki mutex'ler priority inheritance ile priority inversion'ı engelliyor.

Tam olarak engellemiyor ancak olumsuz etkilerini azaltıyor.

[yamak]

Yani düşük öncelikli thread in priority sini geçici olarak yükseltiyor. Böylece araya başka thread giremiyor. Tabi bu durumda ortanca öncelikli thread in çalışması gecikiyor. Ama dediğim gibi round robin ile de bu şekilde time critical sistem tasarlanamıyor.