Thread: Helping application programmers catch threading bugs

Based on this thread:

http://archives.postgresql.org/pgsql-admin/2009-04/msg00100.php

I was wondering whether it would make sense to add a checkThreading
method to help programmers who make such mistakes catch them more
easily.  Unfortunately I can't think of a reliable way to do this
without using synchronized blocks, but maybe someone else can.  In any
event, I don't think we'd want to do it if there is a significant
performance hit, but I bet the cost would be "lost in the noise" of
measurement.

Perhaps defined something like:

    private Thread currentThread = null;
    private int    useCount = 0;
    public synchronized void checkThreading() throws PSQLException
    {
        if (currentThread != null && currentThread !=
Thread.currentThread())
        {
            throw new PSQLException(GT.tr("Multithreading error;
another thread is currently using the connection."), PSQLState.?);
        }
        currentThread = Thread.currentThread();
        ++useCount;
    }
    public synchronized void checkThreadingExit() throws PSQLException
    {
        if (useCount <= 0 || currentThread != Thread.currentThread())
        {
            throw new PSQLException(GT.tr("Multithreading error;
invalid state found on method exit."), PSQLState.?);
        }
        if (useCount-- == 0)
        {
            currentThread = null;
        }
    }

It would be used along the lines of (for example):

    public java.sql.ResultSet executeQuery() throws SQLException
    {
        checkThreading();
        try
        {
            <existing code here>
        }
        finally
        {
            checkThreadingExit();
        }
    }

Would this be a sane and worthwhile thing to do?

-Kevin

I wrote:
>        if (useCount-- == 0)

Of course that should be:

        if (--useCount == 0)

-Kevin

On Mon, 13 Apr 2009, Kevin Grittner wrote:

> Based on this thread:
>
> http://archives.postgresql.org/pgsql-admin/2009-04/msg00100.php
>
> I was wondering whether it would make sense to add a checkThreading
> method to help programmers who make such mistakes catch them more
> easily.

The JDBC spec requires a Connection to be thread safe.  Ideally it should
be able to issue queries in parallel, but PG can't do that, so we block
instead.  There are subtle threading bugs in the JDBC driver, but they're
below the Connection level, for unusual things like executing a
PreparedStatement while issuing setXXX calls on the same object from
another thread.

Reading the thread didn't reveal an adequate description of the actual
problem, so it's not clear if there's anything to be done here or if it
was operator error.

Kris Jurka