Statechart ve Meta State Machine karşılaştırması

Görünüşe göre boost, durum makineleri için iki ayrı kitaplık içeriyor: Statechart ve Meta State Machine (MSM). Sloganlar çok benzer açıklamalar verir:

• Boost.Statechart - Rasgele karmaşık sonlu durum makineleri kolayca okunabilen ve bakımı kolay C ++ kodunda uygulanabilir.
• Meta State Machine - Etkileyici UML2 sonlu durum makineleri için çok yüksek performanslı bir kütüphane.

Temel farkların ne olduğunu ve ikisi arasında seçim yaparken dikkat edilmesi gereken hususları biliyor musunuz?

Çok fazla ilgi var gibi göründüğünden, lütfen (açık bir şekilde önyargılı) fikrimi vermeme izin verin, bu nedenle bir tuz tanesi ile alınmalıdır:

• MSM çok daha hızlı
• MSM RTTI veya sanal bir şey gerektirmez
• MSM'nin daha eksiksiz bir UML2 desteği vardır (örneğin dahili geçişler, UML uyumlu dikey bölgeler)
• MSM açıklayıcı bir dil sunar (aslında birkaç tane). Örneğin, eUML ön ucunu kullanarak bir geçiş Kaynak + Olay [Güvenlik] / Eylem == Hedef olarak tanımlanabilir
• MSM, derleyicinizin daha büyük durumlu makineler için acı çekmesini sağlayacaktır, bu nedenle oldukça yeni bir derleyiciye ihtiyacınız olacaktır (g ++> = 4.x, VC> = 9)

MSM incelemesi sırasında yayınlanan yorumları arayarak kendinize daha iyi bir fikir verebilirsiniz. Bu konu geliştirici listesinde çok tartışıldı.

Christophe'nin daha önce de belirttiği gibi, iki kütüphane arasındaki temel farklardan biri çalışma zamanı performansıdır. MSM muhtemelen burada elde edebileceğiniz en iyisini sunar, ancak Statechart bellek ve işlemci döngülerini bilinçli olarak daha iyi ölçeklenebilirliğe doğru alır.

Boost.Statechart ile durum makinenizin düzenini (örn. Durumlar, geçişler) MSM ile yapamayacağınız şekilde birden fazla çeviri birimine (cpp dosyaları) dağıtabilirsiniz. Bu, büyük FSM'lerin uygulanmasını daha sürdürülebilir hale getirmenizi ve MSM'den daha hızlı derleme elde etmenizi sağlar.

Statechart'ın MSM ile karşılaştırıldığında performans ek yükünün gerçekten önemli olup olmayacağı, uygulamanızın saniyede kaç olayı işlemesi gerektiğini kendinize sorduğunuzda yanıtlamak genellikle oldukça kolaydır.

Boost.Statechart ile uygulanan orta derecede karmaşık bir FSM varsayarsak, burada birkaç ballpark numarası vardır:

• Mevcut PC donanımlarının çoğu saniyede 100.000 olayla kolayca başa çıkacaktır
• Çok kaynak kısıtlı donanımlar bile saniyede birkaç yüz olayı işleyebilecek.

CPU yüküne ilişkin olarak, işlenecek olay sayısı bu sayılardan çok daha düşükse, Boost.Statechart yükü MSM ile karşılaştırıldığında neredeyse kesinlikle fark edilmeyecektir. Sayı çok daha yüksekse, MSM ile kesinlikle daha iyi durumdasınızdır.

Performans / ölçeklenebilirlik değişimleri hakkında daha ayrıntılı bilgi burada bulunabilir: http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html

Kendi PPP uygulamamı kodlarken Statechart'ı üç nedenden dolayı kullandım: 1) Statechart daha basit ve daha açık belgelere sahip; 2) UML'den gerçekten hoşlanmıyorum :)

Yükseltme belgeleri, MSM'nin en az 20 kat daha hızlı olduğunu, ancak büyük FSM için oldukça yavaş derlendiğini söylüyor.

Bir süre önce Statechart ile başladım ve MSM'ye geçtim çünkü tek bir iş parçacığından asio ile birlikte kullanımı daha kolaydı. Statechart ve onun çoklu kullanım yeteneklerini asio kullanımımla birleştirmeyi başaramadım - muhtemelen benim tarafımdan Statechart'ın bir çeşit acemi anlamasıydı. Çok iş parçacığına değinmediği için MSM'nin kullanımının daha kolay olduğunu gördüm.

Tim'in tartışmaya geç girişine cevap olarak (Lev'in ilk yorumlarından birini de ele alır).

Boost'a gönderildiğinde statekarda yıkıcılardan ayrılmasını savunanlardan biri olarak (gerçek kullanım örneğine dayanan, gerçek dünya ile etkileşim hakkında tartışma / G / Ç), Artırma'ya gönderildiğinde çıkış yapmanın sorunları olabileceğini kabul ediyorum yıkıcılarda mantık. David Abrahams, istisna güvenliği konusunda da şaşırtıcı bir şekilde ikna edici argümanlar yaptı. Bu nedenlerden ötürü Statechart, mantık yıkıcılara koymanızı gerektirmez - ancak normal tavsiyelerde bulunmanıza izin verir.

Sadece bir durumdan (statechart nesnesinin bir bütün olarak yok edilmemesi) bir geçişin parçası olarak çalışması gereken mantık ayrı bir çıkış () eylemine ayrılabilir (ve yapılması gereken bir kaynak temizliği varsa).

Etkin durumu (kaynakları) olmayan "ince" bir durum için, yalnızca gerçekleştirilecek giriş / çıkış eylemleri için, bu eylemleri ctor ve d'tor'da gerçekleştirebilir ve yapıcı ve yıkıcıların atmadığından emin olabilirsiniz. Onlar için hiçbir neden yok - RAII yapmak için bir durum yok - bu yerlerde hataların ele alınmasının uygun olayları ortaya koymasında kötülük yoktur. Yine de, harici durumu değiştiren çıkış eylemlerinin durum makinesi imhası üzerinde çalışmasını isteyip istemediğinizi düşünmeniz gerekebilir ve bu durumda bunların olmasını istemiyorsanız bunları çıkış eylemine sokabilirsiniz ...

Statechart, etkinleştirmeyi bir nesnenin somutlaştırılması olarak modeller; bu nedenle, kurucunuzda yapılacak gerçek iş / aktivasyon / somutlaştırma varsa ve durum girilemeyecek şekilde başarısız olursa, Statechart bunu bir istisna ile eşleştirme yeteneği vererek destekler Etkinlik. Bu durum, yığının çağrı yığını tabanlı bir çağırma modeli için yığının açılma biçimine benzer şekilde, istisna olayını işleyen bir dış durumu arayan durum hiyerarşisini çalıştıran bir şekilde ele alınır.

Bunların hepsi iyi belgelenmiştir - Dokümanları okumanızı ve denemenizi öneririm. "Yazılım kaynaklarını" temizlemek için yıkıcıları kullanmanızı ve "gerçek dünyadan çıkış eylemlerini" gerçekleştirmek için eylemlerden çıkmanızı öneririm.

İstisna yayılımının yalnızca olay çizelgelerinde değil, tüm olay odaklı ortamlarda bir sorun olduğunu da belirtmek gerekir. Hatalar ve hataları durum çizelgesi tasarımınıza dahil etmek ve dahil etmek en iyisidir ve yalnızca bunları başka bir yolla ele alamazsanız istisna eşlemesine başvurunuz. En azından benim için çalışıyor - ymmmv ....