Mutex éles/lightweight módban

Probaltal mar spinlockokat hasznalni? Ha viszonylag ritka a varakozas a mutexen, akkor jo lehet, mivel kifejezetten alacsony a koltsege (nem feltetlen jar kontextusvaltassal, peldaul).

----------------------
while (!sleep) sheep++;

Tudom, jelentősen elkalandozok az eredeti felvetéstől:

sajnos se azt nem tudni, hogy milyen események vannak, milyen adatstruktúrát kell szétházmozni (és ez mennyi erőforrásba kerül) illetve hogy mennyire sebességkritikus a rendszer.
Ha kevésbé sebességkritikus és az adatstruktúra viszonylagosan konzisztens és gyorsan lehet házmoni, illetve belefér egy minimál latency az eseményekre való reagálásra, akkor elgondolkoznék valami belső message pump rendszeren. Így mivel külön thread foglalkozik ezzel a résszel egyedül, nem kell lockolni az adatstruktúrát, a message pump pedig már helyből sorba szedi az üzeneteket (így elvileg minden oldalról elkerülhető a lockolás). Ez a message pump hasonló mint egy FIFO, igazából egy queue rendszer, de pont az ilyen helyzetekre jó. Bár ez nagyon sok helyzetben nem működik, viszont kevésbé igényes mint a lockolás, viszont ha a cél engedi, akkor nagyon jól működik, viszont hardware oldalról kell sok és nagyon gyors ram alá

1. Ha jól értem, akkor "hagyományos" mutexekből és conditional variable-kből hekkeltetek össze egy read-write lockot. Mi lenne, ha inkább "igazi" RW lockot használnátok, pl. pthread_rwlock_t? Mivel a szinkronizáció lényegileg nem változik, ezt lehet, hogy viszonylag kevés változtatással meg lehetne úszni.

2. Ha tényleg nagyon sokkal több olvasás van, mint írás, és a szóbanforgó megosztott adatstruktúra nem túl nagy vagy az írások ritkák, és szinkronizálás szempontjából elég, ha az olvasó szálak egy konzisztens snapshotot látnak a megosztott adatstruktúrából, akkor meg lehet próbálkozni egy copy-on-write adatstruktúrával.

Gondolom, van az adatstruktúrádnak egy kiindulási pontja, legyen ez egy globális pointer. Az update menjen úgy, hogy a pointert csak akkor frissíti be, ha teljesen felépült az új adatszerkezet. Tehát azonnal átváltasz a régi adatról az újra, nem kell várakozni arra, hogy legyen adat. Ha ezen felül fontos, hogy a változást azonnal lássák az olvasók, akkor megteheted azt, hogy olvasás előtt és után összehasonlítod a pointert, és ha nem egyezik, akkor újra elvégzed az olvasást. Gyk. optimista lock.

Ennek egy egyszerűbb verziója, ha nem akarsz olvasást ismételni, hogy van egy globális boolean változód, ami mutatja, hogy éppen folyamatban van-e az update. Ha ez true, akkor valamilyen módon az olvasók kivárják, hogy false legyen. Összeakadással nem kell foglalkozni, csak garantáld azt, hogy ha valaki elkezdett a régi adatokkal dolgozni, akkor az mindig be is tudja fejezni, tehát csak később semmisítsd meg a korábbi adatokat. Ezt mondjuk menedzselt nyelvben lenne sokkal egyszerűbb megoldani.

By the way, ez csak egy ötlet, nehéz jót mondani konkrét számok nélkül. Igazából ha már egy read lock is lassú, akkor ott valamit nagyon elszúrtál, és amiket itt ajánlgatunk, az lehet hogy x%-kal gyorsabb lesz, de 10x%-kal hekkelősebb. Én inkább erőltetném a library vagy OS által ajánlott szinkronizációs primitíveket, mint a fentebbi trükkjeimet.

--
joco voltam szevasz

1. A témaindító leírás nem győzött meg arról, hogy a mutexért versengnének, sem arról, hogy a mutexet drága volna használni. Szerintem amíg ezt nem bizonyítottátok be (= nem mértétek meg), addig szerintem felesleges és veszélyes bonyolítani a szinkronizációt.

2. Ha az első ponton már túl vagytok, akkor javaslom, hogy olvasd végig ezt a fejezetet. Nem lehetetlen, hogy platformfüggő vagy C++0x primitívekre lesz szükséged.

Én az rwlock-tól egy kicsit idegenkedem. Ha olyan implementációt használsz, amely az olvasóknak kedvez, akkor az író éhezhet. Ha olyan implementációt használsz, amely az író szándéknyilvánítása után az új olvasókat már nem engedi be, akkor az írón keresztül a már futó olvasók tartják fel az új olvasókat.

Az MVCC nekem (is) jobban tetszik. Alant egy atomgagyi referenciaszámlált változat. (Lefordítani sem próbáltam.) Elvileg akárhány reader és writer konkurálhat, és a cucc READ COMMITTED láthatóságot biztosít.

Az adatszerkezet gyökerében van egy számláló. (Gyökéren valójában egy vékony wrapper-t, "verziót" értek a lényegi adatok körül.) A számlálót egy mutex védi. A gyökérre mutat egy pointer ("friss verzió"). A pointert szintén egy mutex védi. Az alábbiak számítanak gyökérreferenciának (= verzióreferenciának):

• A gyökérre mutató "friss verzió" pointer.
• Minden szál, amely az adott verzióval dolgozik.

Csak read-only referenciák léteznek.

Utility definíciók, pszeudokód:

struct root
{
  unsigned refno;
  mutex_t refno_lock;

  void *user_data;
};

static struct root *rootptr;
static mutex_t rootptr_lock;

/* Return the current version and add a reference to it. */
struct root *
acquire_current(void)
{
  struct root *current;

  lock(&rootptr_lock);
  current = rootptr;
  lock(&current->refno_lock);
  ++current->refno;
  unlock(&current->refno_lock);
  unlock(&rootptr_lock);

  return current;
}

/*
  Release the reference. Return a boolean value corresponding
  to whether this was the last reference. If this was the last
  reference, free the wrapper, and store the user data in
  *old_user_data.
*/
int
release_copy(struct root *mycopy, void **old_user_data)
{
  unsigned after;

  lock(&mycopy->refno_lock);
  after = --current->refno;
  unlock(&mycopy->refno_lock);
  if (0u == after) {
    *old_user_data = mycopy->user_data;
    lock_uninit(&mycopy->refno_lock);
    free(mycopy);
    return 1;
  }

  return 0;
}

/*
  Set the next version of the object. Return values:
  -1 -- malloc() failed; nothing is changed.
   0 -- success, and the replaced version
        is still referenced by others.
   1 -- success, and the last reference
        to the replaced version was removed.
*/
int
set_next(void **old_user_data, void *new_user_data)
{
  struct root *next;

  next = malloc(sizeof *next);
  if (0 != next) {
    struct root *current;

    next->refno = 1u;
    lock_init(&next->refno_lock);
    next->user_data = new_user_data;

    lock(&rootptr_lock);
    current = rootptr;
    rootptr = next;
    unlock(&rootptr_lock);

    return release_copy(current, old_user_data);
  }

  return -1;
}

Reader-ek kódja:

struct root *mycopy;
void *old_user_data;

mycopy = acquire_current();

use(mycopy->user_data);

if (release_copy(mycopy, &old_user_data)) {
  destroy(old_user_data);
}

Writer-ek kódja:

struct root *mycopy;
void *new_user_data,
    *old_user_data;

mycopy = acquire_current();

prepare_next(&new_user_data, mycopy->user_data);

if (release_copy(mycopy, &old_user_data)) {
  destroy(old_user_data);
}

switch (set_next(&old_user_data, new_user_data)) {
  case -1:
    destroy(new_user_data);
    break;
  case 1:
    destroy(old_user_data);
}

De mondom, ez a zárakkal megoldott MVCC jellegű izé atomgagyi; legjobb esetben is csak annyi mondható el róla, hogy hordozható. Normális esetben valamilyen CAS-t használnak.