Oracle MERGE priekšraksts (jeb upsert) ļauj ar vienu operāciju izmainīt ierakstu vai pievienot to, ja šāds ieraksts vēl neeksistē. Apmēram:
IF ieraksts atrasts
THEN UPDATE
ELSE
INSERT;
Kas nav acīmredzams, bet patiesībā loģisks rezultāts: veicot operāciju ar primāro atslēgu “ON” daļā ir iespējams iegūt kļūdu “ORA-00001: unique constraint (…) violated”. Respektīvi – starp brīdi, kad Oracle noskaidro, ka ieraksts neeksistē un veic INSERT, kāds cits process, veicot MERGE operāciju, var paspēt izpildīt INSERT pirmais.
Atbilstoši C/C++ standartiem, kompilatoram no šķietami pareiza koda ir tiesības ģenerēt dīvainu rezultātu, ko tas arī dara.
#include <pthread.h>
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
static int acquires_count = 0;
int
trylock()
{
int res;
res = pthread_mutex_trylock(&mutex);
if (res == 0) {
++acquires_count;
}
return res;
}
Kompilēšanas rezultāts ir ekvivalents šādam kodam:
int
trylock()
{
int res;
int tmp;
res = pthread_mutex_trylock(&mutex);
tmp = acquires_count;
if (res == 0) {
++tmp;
}
acquires_count = tmp;
return res;
}
EPIC FAIL!
Palīdzēt var ar volatile vai skaitītāja palielināšanu liekot citā funkcijā. Bet svarīgi atcerēties, ka vairākpavedienu programmās būs jācīnās ne tikai ar algoritma kļūdām, paralēlu izpildi gan vairāku procesoru, gan viena procesora out-of-order izpildes līmenī, procesora spekulācijām, bet arī ar kompilatora optimizācijām.
Gallery of Processor Cache Effects sevišķi interesants ir 6. piemērs par vairākpavedienu programmām. Nevajag vienu globālu mainīgo, lai programmā radītu šauro vietu – pietiek ar to, ka mainīgie, ko izmanto dažādi pavedieni, atrodas tuvu viens otram atmiņā. Procesoriem būs darba pilnas rokas, sinhronizējot savas kešatmiņas.
Tā nu sanāca, ka vakar noskatījos ekstrasensu cīņu finālu. Smieklīgi, ka finālā tika saņemtas tikai 50,000 balsis. Krievijas šovam! Bet es zinu kā šo šovu var padarīt populārāku:
Überšovā vajadzēja piedalīties ekstrasensiem un viņu ģimenēm un dziedāt kopā ar kori no dzimtās pilsētas. Tad ekstrasensam būtu jādejo pārī ar profesionālu dejotāju. To visu jāvērtē 3 cilvēku žūrijai: viens jackass un divi draudzīgi locekļi, ja šovu rādīs pa TV3; trīs draudzīgi un laipni locekļi bez mugurkaula, ja šovu rādīs pa LNT. Piedevām, ekstrasensiem būtu jācīnās par raidījuma vadītāja sirdi un jāpelna sarkanas rozes.
Protams, iznākumu šim šovam var paredzēt uzreiz – uzvarēs tas ekstrasenss, kura dzimtā pilsēta būs Latgalē.
Sestdienas rītā, kad ārā temperatūra kādi mīnus 15, uzvilku ziemas jaku un krosenes, iekāpu mašīnā un aizbraucu uz veikalu. Šortos. Pēc tam bija stipri jāsakož zobi, lai nesmietos par cilvēku izbolītajām acīm. Bet man nesalst.
Tas atgādināja bērnību, kad 90. gados dobokā un basām kājām trenējāmies nekurinātās vai slikti apkurinātās sporta zālēs un pusstunda pagāja, līdz atkal varēja just kāju pirkstus. Uz beigām treneris kļuva apsēsts ar “Детка” ideju un vairākas reizes treniņi notika tajos pašos dobokos basām kājām sniegotā mežā. Beidzās ar to, ka es aizgāju trenēties uz citu klubu.
Mazliet pārfrāzējot: programmētājam bija ātrdarbības problēma un viņš nespēja atrast risinājumu. “Zinu,” viņš teica, “es lietošu vairākus pavedienus.” Tagad programmētājam bija divas problēmas.
Ik pa brīdim uzrodas kāda diskusija par Python GIL likvidēšu. Tā ir “ļaunuma sakne”, kuras dēļ Python vairākpavedienu programmas nespēj izmantot vairākus procesorus, jo vienlaicīgi tiek izpildīta tikai viena instrukcija un darbojas viens pavediens. Oficiālā atbilde šādos gadījumos ir lietot Jython vai neatkarīgus procesus pavedienu vietā.
Arī jaunākajā Python 3k versijā GIL joprojām ir, bet ar dažiem uzlabojumiem. Ja piever acis uz tehnisko realizāciju, šajā prezentācijā ir pāris interesanti fakti:
Šobrīd, “optimizējot” ar vairākiem pavedieniem un paralēlu izpildi, tiek sasniegts negatīvs rezultāts – prezentācijas piemērā uzdevums tiek veikts 1.8 reizes lēnāk.
Nākošajās Python versijās vairākpavedienu programmas strādās gandrīz tikpat ātri kā viena pavediena programmas.
Tāpēc, ja vien programmas šaurā vieta nav I/O (bieži ir), tad par vairākiem pavedieniem Python programmās ir jāaizmirst.
Meklējot precīzos vārdus citātam par Perl izrādījās, ka kopš 2009. gada Erik Naggum vairs nav. Pirms vairākiem gadiem es izklaides pēc lasīju comp.lang.lisp diskusijas ar viņa piedalīšanos apmēram to pašu īpašību dēļ kā tagad skatos dakteri Hausu. Viņš bija Lisp programmētājs, kas ienīda Perl, XML, C++, cilvēku stulbumu, mācīšanās vēlmes trūkumu, prata argumentēt savus uzskatus un nekad nepalika vārdu parādā.
Tas viss ir jautri, kamēr nav vērsts pret tevi.
Kaut kur pusceļā starp RDBMS un NoSQL atrodas FcukSQL pasaule.
No vienas puses FcukSQL grib izmantot SQL, nevis manuāli rakstītu meklēšanas/grupēšanas/summēšanas kodu, grib vairākus(!) indeksus, ACID transakcijas un RDBMS administrēšanas rīkus. Un pilnībā pietiek ar viena datu bāzes servera jaudu. No otras puses – grib “lidojumā” maināmas datu struktūras, glabāt nestrukturētus datus (schema-less) un taisīt indeksus šiem nestrukturētajiem datiem.
Tad rodas risinājumi, kas “izvaro” RDBMS un glabā serializētus datus vai tabulas ar key-value pārīšiem. Bet kaut ko tādu nākas redzēt pirmo reizi:
Kāds ir uzrakstījis diezgan labu rakstu par malloc() kļūdu apstrādi dažādās atvērtā koda programmās un bibliotēkās. Visus variantus atgremot nav vērts, tomēr vispopulārākā stratēģija ir kļūdas ziņojums un priekšlaicīgā procesa pārtrauce (abort), kas ir saprātīgs kompromiss starp mēģinājumu apstrādāt kļūdu un nekā nedarīšanu.
Arī komentāri lasīšanas vērti. Ir interesanta versija (ļoti ticami, bet precīzi pārbaudījis neesmu): malloc() uz Linux pēc noklusēšanas vienmēr atgriezīs ne-NULL adresi. Atmiņa tiks izdalīta tikai brīdī, kad mēģinās rakstīt šajā adresē un programmu nokaus OOM killer.
Pēc šī teksta vēlme apstrādāt malloc() kļūdas vēl vairāk tuvojas nullei.
Š ādu saiti uzgāju, lasot coding horror rakstu par atmiņas vadību . Vairums jauno un moderno programmēšanas valodu ir atbrīvojušās no “drausmīgās” manuālas atmiņas vadības ar new/delete, malloc/free. Bet problēma drīzāk ir acquire/release šablons, kas joprojām ir sastopams daudzās programmās. Es runāju par kaut ko šādu, kur resource ir fails, pieslēgums pie datubāzes, pavediens:
Aizmirstā release problēma joprojām ir aktuāla. Tāpēc man liekas, ka lielākais (automātisko) drazu savācēju trūkums ir tāds, ka tie veic tikai atmiņas resursu vadību. 60-ajos gados tas tiešām bija aktuāli, bet mūsdienās pat “Hello world” lasa vairākus konfigurācijas failus, slēdzas pie datubāzes, Web serveriem un šiem resursiem ir tendence izbeigties ātrāk nekā atmiņai. Problēma tiek slēpta, veicot drazas savākšanu biežāk, vairāk un pat paralēli programmas izpildei. Kaut kādi uzlabojumi šajā jomā ir sastopami C# un Ruby ar paredzamu resursu vadību koda bloka ietvaros, bet man arvien vairāk sāk likties, ka atsauču skaitīšana un RAII ir pareizāks risinājums. Tik daudz darba tiek veikts, lai tuvinātos paredzamai resursu atbrīvošanai – varbūt tā bija jādara no paša sākuma?
