> > (2) the killer function is PGSemaphoreReset(). There is no direct
> > function for this in Win32 either.
>
> If you can do PGSemaphoreTryLock, then Reset need only be a
> loop around it (cf. posix_sema.c). In current usage Reset
> doesn't have to be very efficient at all, because it's only
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> (2) the killer function is PGSemaphoreReset(). There is no direct function
> for this in Win32 either.
If you can do PGSemaphoreTryLock, then Reset need only be a loop around
it (cf. posix_sema.c). In current usage Reset doesn't have to be very
effici
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote
>
> So we might want to fix current win32/sema.c for two problems:
> (1) semctl(SETVAL, val=0) - there is no other "val" than zero is used;
> (2) concurrent access to sem_counts[];
>
Attached is a patch for the above proposed change -- but still, I hope w
""Magnus Hagander"" <[EMAIL PROTECTED]> wrote
> >
> > I'm not sure why the win32 port chose to emulate the SysV
> > semaphore interface anyway. You could equally well have used
> > the Posix interface (src/backend/port/posix_sema.c). Or,
> > given Microsoft's NIH tendencies, you might have neede
> > Looking at the code, it looks fairly complex to me. I don't really
> > know how sysv semaphores are supposed to work, or how we
> use them, but
> > perhaps the whole piece of code can be simplified?
>
> I'm not sure why the win32 port chose to emulate the SysV
> semaphore interface anyway.
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Looking at the code, it looks fairly complex to me. I don't really know
> how sysv semaphores are supposed to work, or how we use them, but
> perhaps the whole piece of code can be simplified?
I'm not sure why the win32 port chose to emulate the SysV
> > As I reviewed the win32/sema.c, there is some code that I am not
> > clear,
> can
> > anybody explain please?
> >
>
> There is another problem related to concurrent operations on
> win32 sema. Say two processes are doing semop(+1)
> concurrently. Look at this code:
>
> /* Don't want the
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote
> As I reviewed the win32/sema.c, there is some code that I am not clear,
can
> anybody explain please?
>
There is another problem related to concurrent operations on win32 sema. Say
two processes are doing semop(+1) concurrently. Look at this code:
/*
As I reviewed the win32/sema.c, there is some code that I am not clear, can
anybody explain please?
In semctl(SETVAL):
if (semun.val < sem_counts[semNum])
sops.sem_op = -1;
else
sops.sem_op = 1;
/* Quickly lock/unlock the semaphore (if we can) */
if (semop(semId, &sops, 1) <
