On Fri, 23 Oct 2009, Andrew Gallatin wrote:
Daniel Eischen wrote:
We already use umtx. This really is a hack and I wouldn't
advocate it. I'm not sure how you could make it work and
not break existing ability to return appropriate error
codes without slowing down the path in the non-shared
c
Daniel Eischen wrote:
We already use umtx. This really is a hack and I wouldn't
advocate it. I'm not sure how you could make it work and
not break existing ability to return appropriate error
codes without slowing down the path in the non-shared
case. You'd have to check to see if the addres
either:
1) use sysv semaphores (ick)
2) use a hand rolled spinlock (ick)
3) use some sort of hack built into our driver (ick, ick)
4) use umtx
Is there some bug or limitation in umtx that makes it inappropriate?
(beyond the obvious, like the potential to leave a resource locked
forever if the lock ho
x and Solaris,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.
We then moved on to posix semaphores. Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms. However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary
D (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.
We then moved on to posix semaphores. Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms. However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary text regarding the ps
ral processes, and has to
> >>>>> run on Linux, Solaris, and FreeBSD. We were planning to
> >>>>> have the lock be a pthread_mutex_t residing in the
> >>>>> shared memory page. This works well on Linux and Solaris,
> >>>>> but FreeBSD
pport
PTHREAD_PROCESS_SHARED mutexes.
We then moved on to posix semaphores. Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms. However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary text regarding the pshared
value:
The sem_init() fun
then moved on to posix semaphores. Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms. However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary text regarding the pshared
value:
The sem_init() function initializes the unnamed sema
;> shared memory page. This works well on Linux and Solaris,
> >>> but FreeBSD (at least 7-stable) does not support
> >>> PTHREAD_PROCESS_SHARED mutexes.
> >>>
> >>> We then moved on to posix semaphores. Using sem_wait/sem_post
> >>> with the sem_t resi
On Thu, Oct 22, 2009 at 04:08:11PM -0400, Andrew Gallatin wrote:
> We then moved on to posix semaphores. Using sem_wait/sem_post
> with the sem_t residing in a shared page seems to work on
> all 3 platforms. However, the FreeBSD (7-stable) man page
> for sem_init(3) has this scary te
mutex_t residing in the
> shared memory page. This works well on Linux and Solaris,
> but FreeBSD (at least 7-stable) does not support
> PTHREAD_PROCESS_SHARED mutexes.
>
> We then moved on to posix semaphores. Using sem_wait/sem_post
> with the sem_t residing in a shared page see
have the lock be a pthread_mutex_t residing in the
shared memory page. This works well on Linux and Solaris,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.
We then moved on to posix semaphores. Using sem_wait/sem_post
with the sem_t residing in a shared page see
page. This works well on Linux and Solaris,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.
We then moved on to posix semaphores. Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms. However, the FreeBSD (7-stable) man
n the
shared memory page. This works well on Linux and Solaris,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.
We then moved on to posix semaphores. Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms. However
,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.
We then moved on to posix semaphores. Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms. However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary text rega
How reliable is the Posix semaphore support in FreeBSD 7 for
interprocess synchronization?
Is it not on by default because no one uses it, or because the code
isn't trustworthy, or some other reason?
Is this what you would recommend for synchronizing access to a shared
resource between processes
On 04/01/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Quoting Ivan Voras <[EMAIL PROTECTED]>:
>
> > For general information on the FreeBSD kernel see the book "Design and
> > implementation of the FreeBSD operating system",
>
> Will this edition be updated, or is it still relevant with the
Quoting Ivan Voras <[EMAIL PROTECTED]>:
> For general information on the FreeBSD kernel see the book "Design and
> implementation of the FreeBSD operating system",
Will this edition be updated, or is it still relevant with the coming of 7.0 ?
It was written with 5.0 in mind, and considerable prog
Neeku Shamekhi wrote:
I need some article about semaphores in freeBSD and mainly about kern_sema.c
file.
man 9 sema
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any
Neeku Shamekhi wrote:
> I need some article about semaphores in freeBSD and mainly about kern_sema.c
> file.
About the best documentation you will find is this:
http://fxr.watson.org/fxr/source/kern/kern_sema.c
For general information on the FreeBSD kernel see the book "Design and
imp
I need some article about semaphores in freeBSD and mainly about kern_sema.c
file.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hello,
I'm tuning some IPC semaphores parameters in 6.1-STABLE for a busy
PostGreSQL server (8.1.4). I still now can not find the value range
(exactly the maximum value) and its dependencies on other system wide
parameters of these parameters: kern.ipc.semmni, kern.ipc.s
--- Peter Pentchev <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 22, 2004 at 12:01:51AM +, Robert
> Watson wrote:
> >
> > On Mon, 13 Dec 2004, Joe Kelsey wrote:
> >
> > > I have a desire to fix posix semaphores in at
> least 5.3. The current
> &
On Wed, Dec 22, 2004 at 12:01:51AM +, Robert Watson wrote:
>
> On Mon, 13 Dec 2004, Joe Kelsey wrote:
>
> > I have a desire to fix posix semaphores in at least 5.3. The current
> > implementation doesn't actually follow the "spirit" of the standard,
>
On Mon, 13 Dec 2004, Joe Kelsey wrote:
> I have a desire to fix posix semaphores in at least 5.3. The current
> implementation doesn't actually follow the "spirit" of the standard,
> even though it technically qualifies in a somewhat degraded sense. I
> refer t
ystem.
Read-only versus other options have absolutely no bearing on this
problem. Unnamed posix semaphores work just fine in this case. I have
built lots of FreeBSD systems on flash with no problems. This "fantasy"
of a problem has no bearing on the issue I want to discuss.
I woul
On Tue, 2004-12-14 at 08:08 -0800, Kamal R. Prasad wrote:
> --- Joe Kelsey <[EMAIL PROTECTED]> wrote:
>
> > I have a desire to fix posix semaphores in at least
> > 5.3. The current
> > implementation doesn't actually follow the "spirit"
> &
do use netbsd that way. For the most part, you
> wouldn't want to create a file on such a system.
Read-only versus other options have absolutely no bearing on this
problem. Unnamed posix semaphores work just fine in this case. I have
built lots of FreeBSD systems on flash with no problems. Th
--- Joe Kelsey <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-12-14 at 08:08 -0800, Kamal R. Prasad
> wrote:
> > --- Joe Kelsey <[EMAIL PROTECTED]> wrote:
> >
> > > I have a desire to fix posix semaphores in at
> least
> > > 5.3. The curre
--- Joe Kelsey <[EMAIL PROTECTED]> wrote:
> I have a desire to fix posix semaphores in at least
> 5.3. The current
> implementation doesn't actually follow the "spirit"
> of the standard,
> even though it technically qualifies in a somewhat
> degraded
I have a desire to fix posix semaphores in at least 5.3. The current
implementation doesn't actually follow the "spirit" of the standard,
even though it technically qualifies in a somewhat degraded sense. I
refer to the fact that the current implementation treats posix
semaphore
"Dimitar V. Peikov" wrote:
>
> I've tryed to make some example on using pthreads and semaphores and found
> that process became blocked if inside of critical section use wait, uwait or
> nanowait finctions. In the attached file if change line : (#if 0) to (#if 1)
>
I've tryed to make some example on using pthreads and semaphores and found
that process became blocked if inside of critical section use wait, uwait or
nanowait finctions. In the attached file if change line : (#if 0) to (#if 1)
the program hangs. I've tested it even with gdb and t
udo-devicer, many instaces of this device may
> be active, all have to share a resource. all instances have to
> synchronize their access to the resource. trying to implement this,
> i ended up with a less powerful version of semaphores. since the
> resultant code became little complex,
p with a
> less powerful version of semaphores. since the
> resultant code became
> little complex, i want to replace that with the more
> generic semaphores.
>
> i checked the include files, but i couldn't find any
> semaphore
> functions(semget,semctl,semop) which are
hi,
i am implementing a pseudo-devicer, many instaces of
this device may be
active, all have to share a resource. all instances
have to synchronize
their access to the resource. trying to implement
this, i ended up with a
less powerful version of semaphores. since the
resultant code became
In article <[EMAIL PROTECTED]> you write:
>On Sun, 13 Feb 19100, Andrey Novikov wrote:
>
>> > You probably want to increase either SEMMNI or SEMMNS.
>>
>> I've noticed that but why are they so "round"? Is there any corelation
>> between all these numbers? I don't want to break my kernel by guessi
On Sun, 13 Feb 19100, Andrey Novikov wrote:
> > You probably want to increase either SEMMNI or SEMMNS.
>
> I've noticed that but why are they so "round"? Is there any corelation
> between all these numbers? I don't want to break my kernel by guessing.
>
> > > options SEMMAP=31
> > > opt
SEMMNI is the number of semaphore ids, i.e., the number of times you
can call 'semget()' without deleting any semaphores. SEMMNS is the
actual number of semaphores in the system, which should be >= SEMMNI.
Of course, you can ask 'semget()' to give you up to SEMMSL sema
> struct seminfo seminfo = {
> SEMMAP, /* # of entries in semaphore map */
> SEMMNI, /* # of semaphore identifiers */
> SEMMNS, /* # of semaphores in system */
> SEMMNU, /* # of und
Take a look at:
sys/conf/param.c:
/*
* Values in support of System V compatible semaphores.
*/
#ifdef SYSVSEM
struct seminfo seminfo = {
SEMMAP, /* # of entries in semaphore map */
SEMMNI, /* # of semaphore identifiers
Hello.
Resently my PostgreSQL daemon died with:
IpcSemaphoreCreate: semget failed (No space left on device) key=5432015, num=16,
permission=600
I figured out that the kernel is out of available semaphores,
I wanted to rebuild it but the problem is that the options
related to semaphores are not
Kent Boortz <[EMAIL PROTECTED]> wrote:
> semget(IPC_PRIVATE, SEMMSL, IPC_EXCL | IPC_CREAT | 0600))
>
> fails with the error "No space left on device".
Since SEMMSL defaults to SEMMNS, this is guaranteed to fail if
anything else is using semaphores.
> I tried
ot; defaults to 60, that's the
maximal number of semaphores allowed in the system (accumulated over
all calls to semget() that are active by the same time).
Also, due to the crocky^H^H^H^H^H^Hfunny concept of SysV IPC, you
might as well run out of semaphore IDs instead (== #calls to semge
I tried to port the Linux sound program GramoFile but failed.
The source was found at
http://cardit.et.tudelft.nl/~card06/
It was easy to make it compile and link, mostly changing to
, and -lcurses to -lncurses. But creating the System V
semaphores fails when trying to play some sound. A
45 matches
Mail list logo
