Weblabor

Két nagyon különböző problémát keversz össze. Az egyik, hogy a globális változók használata szorosan csatolt kódot eredményez: ha két függvény ugyanazt a globalt használja, akkor hatással vannak egymás viselkedésére, csatolás (coupling) van közöttük. Ez azt jelenti, hogy ha egy globalt használó függvény viselkedését módosítod, és tudni akarod, hogy ennek a módosításnak pontosan milyen hatása lesz a program viselkedésére, akkor az egész kódbázist át kell rágnod elejétől a végéig, hogy használja-e valami más azt a változót (és nyilván használja, különben minek lenne global); ami használja, annak megváltozik a viselkedése, amivel megváltoztathatja más globalok értékét; goto 1. Ha nagyobb kódbázisról van szó, jónéhány álmatlan éjszakát fogsz eltölteni azzal, hogy egy greppel felfegyverkezve próbálod feltérképezni a függvényeid közötti függőségeket (aztán néhány továbbit akkor, amikor élesben beborul a kód, mert valaki valahol nem greppelhető módon használta azt a változót).

Egy osztály változójáról ezzel szemben pontosan tudod, hogy a kód melyik része fér hozzá; az osztálystruktúra explicitté teszi a függőségeket, a legtöbb módosításról viszonylag könnyű ránézésre megállapítani, hogy helyes.

Ettől teljesen eltérő kérdés, hogy van-e állapota egy függvénynek/objektumnak. Általában igaz, hogy minél kevesebbnek van, annál jobb (könnyebb érvelni a kód helyességéről), OOP-ben ezt tipikusan úgy oldod meg, hogy szétbontod a kódot value objectekre, amikben csak állapot van, logika nincs, és service-ekre, amikben csak logika van, állapot nincs. Ennél extrémebb megközelítés a funkcionális paradigma, ahol egyáltalán nincsenek állapotok, ami nagyon elegáns, de kevésbé illeszkedik a valóságra (ha felhasználói interakciót kell kezelni, vagy I/O-t, akkor ott ugye az állapotosság külső adottság), meg a processzor működésére (aminek a középpontjában a regiszterek állapotának az állítgatása áll).

Én értem mire gondolsz, de aki esetleg nem ismeri, annak picit félrevezető lehet ez a definíció. Azt jelenti a reentrancy, hogy a függvény menet közben megszakítható, újra meghívható, majd a második hívást követően az első a második hívás futásától függetlenül helyes eredményt ad. Ennek egyik következménye, hogy a reentrant függvénynek nem lehet olyan függősége, amit ő maga módosít, így például nem függhet egy globális változón, amit ír.

Ahogy ez ebből látszik is, a reentrencynek van többszálú aspektusa is, vagyis egy reentrant függvényt több szálból párhuzamosan meghívva, a különböző szálakon futó függvények nem módosítják egymás viselkedését. Ebből következően nem függhetnek olyan adaton, amit ők maguk módosítanak, és több szálból is elérhetőek, vagyis shared adaton. A reentrancy utóbbi definícióját szokták keverni a thread-safetyvel, de a kettő kicsit mást jelent. Egy thread-safe függvény használhat shared adatot, viszont biztosítania kell, hogy a konkurrens hozzáférés ne zavarja össze a működését, pl a hozzáférés szinkronizálásával (lock).

És hogy ez még viccesebb legyen, a reentrancy fogalma létezik a lockok esetében is: a reentrant lock engedélyezi a lockot "fogó" szál számára a lockkal védett kódblokkba az újbóli belépést (pl rekurzió). Pl a Java synchronized metódusai és blokkjai reentrant lockként viselkednek.

Még talán annyi, hogy az nem negatív minősítése egy függvénynek, hogy reentrant, vagy sem, így a globális változókat használó függvények nem emiatt ördögtől valók, hanem mert közös lónak túros a háta :)