Hi Tatsuo,

There are places like health_check() where backend_status is being set
without holding any semaphores and also in the main loop after getting the
health status, the Req_info is updated without holding onto the
REQUEST_INFO_SEM.  There are other cases where the semaphore isn't held
while updating shared memory data structures, like send_failback_request()
which is called by the PCP process.  Is there something I'm missing?

Thanks.

On 9/3/08, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > I'm looking at the source code for PGPool II 2.1. And I have a question
> > regarding concurrent read/write access to the BackendInfo structure in
> > shared memory. There are calls like VALID_BACKEND(i) or
> > BACKEND_INFO(i).backend_status = CON_DOWN, which seem to be called
> > concurrently without holding any mutexes. It seems that setting the
> > backend_status is ok, since it's an enum and is an atomic operation.
> > However, VALID_BACKEND() isn't really an atomic operation, but may still
> be
> > ok:
> >
> > ((BACKEND_INFO(backend_id).backend_status == CON_UP) || \
> > (BACKEND_INFO(backend_id).backend_status == CON_CONNECT_WAIT))
> > A bigger issue seems to be that without the use of mutexes or semaphores,
> > how does PGPool guarantee the memory state for the backend status is
> > consistent across different processor cores?
>
>
> Actually semaphores are used. Try to grep pool_semaphore_lock etc.
>
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
>
_______________________________________________
Pgpool-hackers mailing list
[email protected]
http://pgfoundry.org/mailman/listinfo/pgpool-hackers

Reply via email to