El Mon, Mar 19, 2007 at 09:10:13AM -0400 Robert P. J. Day ha dit: > On Mon, 19 Mar 2007, matze wrote: > > > El Mon, Mar 19, 2007 at 06:04:38PM +0530 Daniel Rodrick ha dit: > > > > > On 3/19/07, Momchil Velikov <chill@xxxxxxxxx> wrote: > > > >Daniel Rodrick wrote: > > > >> I may be wrong, but from what I understand, the count passed in the > > > >> semaphore initialization > > > >> > > > >> sema_init(sem, count); > > > >> > > > >> is the number of threads that are allowed to hold the semaphore > > > >> simultaneously (no of threads that are allowed to enter their critical > > > >> sections simultaneously). So can't a semaphore be actually held > > > >> recursively? > > > > > > > >Semaphores are not "held". See below. > > > > > > > >> Also, the only difference I could find between a semaphore and mutes > > > >> is that a mutex is a specail and most common form of semaphore where > > > >> only one thread can get it at a time. Are there any other differences? > > > > > > > >The difference is that a semaphore has no owner. Neither semaphores nor > > > >mutexes are a "special form" of the other - they are fundamentally > > > >distinct mechanisms. > > > > > > > > > > But I see mutexes implemented using semaphores only: > > > > > > #define __DECLARE_SEMAPHORE_GENERIC(name,count) \ > > > struct semaphore name = __SEMAPHORE_INITIALIZER(name,count) > > > > > > #define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name,1) > > > #define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name,0) > > > > that's the deprecated mutex API based on semaphores, AFAIK the one > > described in http://lwn.net/Articles/167034/ should be used > > sorry to be repetitive here, but i'm slightly confused by this passage > from that LWN article: > > "Now that this code has been merged, the semaphore type can officially > be considered to be on its way out. New code should not use > semaphores, and old code which uses semaphores as mutexes should be > converted over when an opportunity presents itself." > > is this actually saying that the semaphore is no longer a necessary > form of concurrency? after all, semaphores can certainly do things > that mutexes can't -- at the very least, semaphores can be initialized > to something other than one, mutexes can't be unlocked by anyone other > than the owner, etc. > > so can someone clarify that passage above? it would *seem* that there > is still a place for a general counting semaphore, no? and also for a binary semaphore i *think* (i'm a kernel newbie ;) that the passage refers only to MUTEXes based on SEMAPHOREs. the following paragraph of the article says: > At this point, code which uses the counting feature of semaphores > lacks a migration path. There is evidently a plan to introduce a new, > architecture-independent type for these users, but that code has not > yet put in an appearance. Once that step has been taken, the path will > be clear for the eventual removal of semaphores from the kernel > entirely. m. -- Ma patrie est où je suis, où personne ne me dérange, où personne ne me demande que je suis, d'où je viens et ce que je fais (B. Traven) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver keys.indymedia.org --recv-keys B9A88F6F `- -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
