DEV: Jak na zamek na databazi?

[Stanislav Meduna]

On Wed, 26 Mar 2003 21:39:12 +0000 (UTC), Pavel Kankovsky wrote:

:> Samozrejme su vynimky. Pokial su tie thready pomerne oddelene
:> a komunikuju cez uzke rozhranie (napr. jeden spracovatelsky
:> thread, jeden UI, informacie si posielaju cez nejaku dobre
:> definovanu frontu a inak si navzajom do dat nelezu), tam
:> toho az tolko pokazit nejde.
: 
: To pak lze udelat stejne dobre misto threadu udelat fork(). :)

Na Linuxe v podstate ano, na inych systemoch je ale switch medzi
procesmi stale vyznamne drahsi ako medzi threadmi. Podobne
su medzi threadmi lacnejsie synchronizacne primitivy
(napr. uz spominany pthread_rwlock sice norma pozna tak medzi
threadmi, ako aj medzi procesmi, na linuxe je vsak naimplementovany
len ten prvy).

Problem je v tom, ze je velmi malo vyvojarov, ktori
o paralelnom spracovani nieco skutocne vedia, a to aj z toho
teoretickeho hladiska. Ani ja sa k nim nepocitam - na to
mam v tejto oblasti prilis malo skusenosti.

Typicky programator bud nelockuje nic s ideou, ze "pri ladeni
sa na to pride", alebo naseka extra primitivu okolo kazdeho
zdielaneho objektu a akonahle potrebuje aspon dva take objekty
naraz, zavari si na deadlock. Ostatne vid jadro - presun
od "big kernel lock-u" k niecomu efektivnejsiemu bol a stale
je dost bolestny.

Este horsia situacia nastane, pokial sa k tomu prida nejaka
snaha o realtime - co na klasickom unixe dynamicke priority
obvykle ako-tak vyriesia, v deterministickom planovani
zdochne. Kolko percent vyvojarov rozumie pojmu priority
inversion?

: Privolavat si boleni hlavy z threadu ma smysl prave a pouze v pripade,
: ze se opravdu vyuzije to, ze sdileji jeden pametovy prostor (pripadne
: dalsi veci jako otevrene soubory).

V systemoch, ktore vyvijame vo firme, su thready na nasledovnych miestach:

- sprava dat v zdielanej pamati - tam su treba nejake "upratovacie"
  ulohy, ktore by nebolo rozumne strkat do schedulingu hlavnej
  aplikacie

- low-level komunikacia - tam je treba na niektore veci reagovat
  rychlejsie ako je minimalna doba, po ktoru hlavna aplikacia
  moze trcat v spracovani poziadavky

- jeden clovek sa raz rozhodol urobit inu "databankovu" aplikaciu
  tak, ze kazdy klient ma vlastny thread. Je to uz par rokov
  a ludia ho doteraz idu za to zabit - kym sa to dostalo
  do stavu vhodneho na predaj (o pouzitelnosti ani nehovoriac ;-)),
  vela ludi si trhalo vlasy.

- quick&dirty svinaciny, ktore nikomu neodporucam a radsej
  o nich pomlcim :-)

Zdravi
-- 
                                    Stano