[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

OT: locking/unlocking schemas with SysV semaphores



Hello guys,

I have an offtopic question, maybe some of the experts
on this list have time to answer it? I have read the UNP
book, man semXXX and searched deja.com too.

If you look into the mm library at 
http://www.engelschall.com/sw/mm/ or
into the Perl module IPC::SharedLite at 
http://search.cpan.org/search?dist=IPC-ShareLite
the following schema is being used:

      mm_core_dolock[0].sem_num   = 0;
      mm_core_dolock[0].sem_op    = 0;
      mm_core_dolock[0].sem_flg   = 0;
      mm_core_dolock[1].sem_num   = 0;
      mm_core_dolock[1].sem_op    = 1;
      mm_core_dolock[1].sem_flg   = SEM_UNDO;

      mm_core_dounlock[0].sem_num = 0;
      mm_core_dounlock[0].sem_op  = -1;
      mm_core_dounlock[0].sem_flg = SEM_UNDO;

I understand the above like this: the semaphore value 0
means locked, and the value 1 means unlocked. Since just
sem_op=+1 wouldn't block, the locking operation above is 
first waiting for the 0 with sem_op=0.

My question is, what are the advantages of using this 
schema and not the (as I think) more simple:

      mm_core_dolock[0].sem_num   = 0;
      mm_core_dolock[0].sem_op    = -1;
      mm_core_dolock[0].sem_flg   = SEM_UNDO;

      mm_core_dounlock[0].sem_num = 0;
      mm_core_dounlock[0].sem_op  = +1;
      mm_core_dounlock[0].sem_flg = SEM_UNDO;

Where 1 means unlocked and 0 means locked. The value of
the semaphore should be initialized to 1 with the first
semctl, so that it's unlocked initially. 

It looks simpler to me, and I have also read that AIX
doesn't follow the order of semop operations (OpenBSD
probably does), so my schema is fail-safer...

I suppose that the first schema handles somehow the 
situation, when a process holding a lock dies. But both 
schemas use SEM_UNDO so it isn't a problem... or is it?

Thanks for reading so far
Alex

-- 
http://home.t-online.de/home/Alexander.Farber/