Re: semaphores and noatomic flag
whould it be possible to use pthread semaphore/mutex/cond_var on shared-via-mmap() chunks of memory instead ? regards -- +--+ |Rossetti Davide INFN - Sezione Roma I - gruppo V, prog. APEmille| | web: http://apegate.roma1.infn.it/~rossetti | |" E-mail : [EMAIL PROTECTED] | ||o o| phone : (+39)-06-49914412 | |--o00O-O00o-- fax: (+39)-06-49914423 (+39)-06-4957697 | | address: Dipartimento di Fisica (V.E.) | | Universita' di Roma "La Sapienza" | | P.le Aldo Moro,5 I - 00185 Roma - Italy| | gnupg pub. key: http://apegate.roma1.infn.it/~rossetti/gnupg.txt| | | |"Outside of a dog,a book is a man's best friend. Inside of a dog, | | it's too dark to read." - Groucho Marx | +--+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: semaphores and noatomic flag
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mihai Moise > > up(semaphore 1) /* wake up client */ > down(semaphore 0) /* put iself to sleep */ > > The problem is that the two system calls make the whole process twice > as slow as it needs to be, and they are both needed because the semop > system call is implemented in an atomic manner. If the semop system > call had an IPC_NOATOMIC flag, then the each process would only have > to do one call, > > semop(up semaphore 0 & down semaphore 1, IPC_NOATOMIC) > > which would be interpreted in the kernel as the sequence of two > system calls I have written previously. On Tuesday 05 June 2001 08:28, Anil Kumar wrote: > Will it not be a very specialized case rather than being general call > type? The concept is general and useful, though I don't think its expression here is correct. A similar feature used in dynix was described earlier in some detail by Paul Cassella: http://marc.theaimsgroup.com/?l=linux-kernel=97742705300697=2 (Re: [RFC] Semaphores used for daemon wakeup) The idea is to atomically release one serializer and grab another. We have quite a few flavors of lock so square that and you have the number of primitives you'd need for a complete set. To sell the idea you'd have to come up with a few places where the new primitives would make the kernel run better, then you'd have to implement it or find someone with the necessary scheduler hacking skills to do it for you. The last part is the tricky one. ;-) -- We had - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: semaphores and noatomic flag
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mihai Moise up(semaphore 1) /* wake up client */ down(semaphore 0) /* put iself to sleep */ The problem is that the two system calls make the whole process twice as slow as it needs to be, and they are both needed because the semop system call is implemented in an atomic manner. If the semop system call had an IPC_NOATOMIC flag, then the each process would only have to do one call, semop(up semaphore 0 down semaphore 1, IPC_NOATOMIC) which would be interpreted in the kernel as the sequence of two system calls I have written previously. On Tuesday 05 June 2001 08:28, Anil Kumar wrote: Will it not be a very specialized case rather than being general call type? The concept is general and useful, though I don't think its expression here is correct. A similar feature used in dynix was described earlier in some detail by Paul Cassella: http://marc.theaimsgroup.com/?l=linux-kernelm=97742705300697w=2 (Re: [RFC] Semaphores used for daemon wakeup) The idea is to atomically release one serializer and grab another. We have quite a few flavors of lock so square that and you have the number of primitives you'd need for a complete set. To sell the idea you'd have to come up with a few places where the new primitives would make the kernel run better, then you'd have to implement it or find someone with the necessary scheduler hacking skills to do it for you. The last part is the tricky one. ;-) -- We had - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: semaphores and noatomic flag
whould it be possible to use pthread semaphore/mutex/cond_var on shared-via-mmap() chunks of memory instead ? regards -- +--+ |Rossetti Davide INFN - Sezione Roma I - gruppo V, prog. APEmille| | web: http://apegate.roma1.infn.it/~rossetti | | E-mail : [EMAIL PROTECTED] | ||o o| phone : (+39)-06-49914412 | |--o00O-O00o-- fax: (+39)-06-49914423 (+39)-06-4957697 | | address: Dipartimento di Fisica (V.E.) | | Universita' di Roma La Sapienza | | P.le Aldo Moro,5 I - 00185 Roma - Italy| | gnupg pub. key: http://apegate.roma1.infn.it/~rossetti/gnupg.txt| | | |Outside of a dog,a book is a man's best friend. Inside of a dog, | | it's too dark to read. - Groucho Marx | +--+ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: semaphores and noatomic flag
Will it not be a very specialized case rather than being general call type? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mihai Moise Sent: Monday, June 04, 2001 11:05 PM To: [EMAIL PROTECTED] Subject: semaphores and noatomic flag I write this to discuss the reasons why the semop system call should have an IPC_NOATOMIC flag. Suppose we have two processes, called client and server, which communicate through a shared memory segment and two semaphores, and need to synchonize their activities so that they don't operate simultaneously except at startup. The server would do, down(smephore 0) to wait for a message from the client. When the client needs the server to execute, it would, up(semaphore 0) /* wake up server */ down(semaphore 1) /* put itself to sleep */ after the server has completed its portion of the task, it would, up(semaphore 1) /* wake up client */ down(semaphore 0) /* put iself to sleep */ The problem is that the two system calls make the whole process twice as slow as it needs to be, and they are both needed because the semop system call is implemented in an atomic manner. If the semop system call had an IPC_NOATOMIC flag, then the each process would only have to do one call, semop(up semaphore 0 & down semaphore 1, IPC_NOATOMIC) which would be interpreted in the kernel as the sequence of two system calls I have written previously. I want to know what other people think about this idea. Mihai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: semaphores and noatomic flag
Will it not be a very specialized case rather than being general call type? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mihai Moise Sent: Monday, June 04, 2001 11:05 PM To: [EMAIL PROTECTED] Subject: semaphores and noatomic flag I write this to discuss the reasons why the semop system call should have an IPC_NOATOMIC flag. Suppose we have two processes, called client and server, which communicate through a shared memory segment and two semaphores, and need to synchonize their activities so that they don't operate simultaneously except at startup. The server would do, down(smephore 0) to wait for a message from the client. When the client needs the server to execute, it would, up(semaphore 0) /* wake up server */ down(semaphore 1) /* put itself to sleep */ after the server has completed its portion of the task, it would, up(semaphore 1) /* wake up client */ down(semaphore 0) /* put iself to sleep */ The problem is that the two system calls make the whole process twice as slow as it needs to be, and they are both needed because the semop system call is implemented in an atomic manner. If the semop system call had an IPC_NOATOMIC flag, then the each process would only have to do one call, semop(up semaphore 0 down semaphore 1, IPC_NOATOMIC) which would be interpreted in the kernel as the sequence of two system calls I have written previously. I want to know what other people think about this idea. Mihai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
