Някой да е срещал нещо фрии по въпроса. Аз съм си написал някакви библиотечки, ама ми се ще да погледна и нещо направено от по-умни хора.

Търси се нещо дето да е леко като за АРМ ембедед система, да е мултитред. И да работи добре за байтове и цели думи. Скоростта е от по-критично значение от универсалността, т.е. не ми трябват C++ имплементации, свързани списъци и т.н.

конкретизарай малко повече, защото има много вариации....
Най-простият вариант е когато имаш по една нишка от всяка страна, тогава стандартния кю си бачка и нямаш нужда от арм трикове.
Ако имаш по повече от една нишка на страна то най-добре да си ги синхронизираш с примитивите на ОС-а (надявам се ползваш ОС). Макар че нещо не схващам смисъла на байт кю и много нишки.
Все пак ако трябва подобна щуротия спокойно може да си сложиш забрана на прекъсванията в push(). А pop() може да го направиш с екслузив достъп.
И спокойно може да си го направиш в Ц++ шаблон ако искаш хем да е универсално хем бързо.

По една нишка е от всяка страна, търкалям плейн С, трябва ми за байтове и думи тръба. Т.е. атомични слагания и вадения.

Нещо май ти е време за почивка, жегата ти идва в повече

Нямаш нужда от атомичности и други циркове... Фифото се прави с един кръгов буфер и два указателя. Единият указател се бара само от едната страна/нишка, другият само от другата. Няма как да стане инфекция, куртексите нямат толкова дълбоки кешове че да ти разбъркат нещата.

Аз така съм го направил. Ама някъде после в момент на временно (надявам се ) умопомрачение, съм го рационализирал и сам наврял вътре и една променлива която инкрементвам и декрементвам съответно при тъпкане и вадене. Идеята ми ... вероятно е била да забързам проверките за състоянието на тръбата. Само дето тая променлива се бара и от двете страни, а инкрементването и декрементването в рама не е атомична операция (нали така). И сега наблюдавам разни странни ефекти... Та ми се прищя да видя нещо написано от по-умни от мен.

Сега ще пробвам да я разкарам въобще и да си смятам глава - опашка както си му е реда.

мда.. трябва да е атомична, ама за къф си го набутваш с общата променлива не знам...



Умниците ги търси за по-смислени неща;-)
Иначе не помня източник, тва по ОС-вете обикновено е по-сложните варианти един към много със синхронизации ала-бала...
По-скоро виж STL или учебникарски примерчета, в Ц++ обикновено ги слагат... То и аз съм правил нещо такова, макар че ти сигурно пак няма да ти хареса че е шаблон. Но точно шаблон е най-подходящ за подобни глупости, компилаторите го мачкат като прасе зрели круши Докато кода си остава прегледен и защитен, ама като те знам по-добре да не ти обяснявам

Един ден като стана голям... вероятно ще мина на C++... ама още съм малък.

малък, ама глупав

вместо да гониш девойките тръгнал да се мъчи с голи Ц

опс, голО Ц имах предвид, ама явно за друго съм си мислел

Мен викаш жегата ме мъчи, а....

Забрана на прекъсванията от двете страни докато пипаш общи неща е гарантирано решение. Предполагам че имаш нужда да защитиш няколко инструкции само, така че си на 6.

А оправих го, просто махнах паразитната променлива. Забрана на прекъсвания не се налага, в най-простия случай двата процеса наистина няма какво да делят.

Без кода е трудно да се разсъждава, но се сещам за две ситуации, в които "си делят":
- проверка за препълване от страна на пишещия
- проверка за празен от страна на четящия
В тези случаи трябва да се сравняват двата пойнтъра, което е потенциална работа със "споделени" променливи?

gicho, май и на теб ти е време да разрешиш "прекъсванията" за по една бира

Имаш два указателя - in & out, които във всеки един момент от времето разделят буфера на пълна и празна част.

Пишештата страна може да маже в празната част колкото и когато си поиска. Никой друг не би трябвало да се интересува какво става там. В момента в който се запише нова стойност, пишештият мести единия указател. Местенето е просто запис, който на почти всички архитектури е атомична операция. Демек останалите до един момент виждат "празно" и изведнъж се появява нова стойстоност и празното е намаляло.

При четенето е по същия начин, четящият може да си чете колкото иска от пълната част и като се начете си мести неговия указател и всички останали изведнъж виждат как празната част се е увеличила.

Зависи от идеологията.
Някои реализации на FIFO при запълване не спират да пълнят, ами презаписват на местото на старите данни ( и естествено, пипат и указателя за четене ). Идеята е, ако за известно време спреш да четеш, да имаш последните, а не първите данни. Там проблеми ще има.

Точно.