Hi J.P.

Must admit I haven't used trylock in the OSG which is possibly why we
haven't hit upon this issue before.

The behavior between Linux and Windows absolutely should the same as
far as we can make it.  The linux implementation also is the one that
is correct and appropriate to use as the reference.

The Win32 implementation has seen a bit of flux, but in general its
currently incarnation using critical sections has been the most
robust, save for the clearly wrong behavior in trylock.  I'm not a
Win32 expert so can't really comment too much.  Paul Martz introduced
the critical section code back last year so perhaps he can shed some
light.  Either way the current code needs to be fixed.

Robert.

On 5/31/07, J.P. Delport <[EMAIL PROTECTED]> wrote:
Hi,

I have been head scratching concerning the following over the past week.
Consider this simple test app:

int main(void)
{
    OpenThreads::Mutex mymutex;
    int tlret;

    tlret = mymutex.trylock();
    printf("-> trylock() returned %d.\n", tlret);
    if (tlret == 0) {
        printf("-> we should have the lock now.\n");
    } else {
        printf("-> we should NOT have the lock now.\n");
    }
    mymutex.lock();
    printf("-> we got past the second lock.\n");
}

I ran this app on Linux and Windows (VS 7.1). For Windows I tried with
USE_CRITICAL_SECTION and without (the old behaviour).

This is what the app prints out:

Linux:
-> trylock() returned 0.
-> we should have the lock now.
app blocks on mymutex.lock()

Windows (without USE_CRITICAL_SECTION):
-> trylock() returned 1.
-> we should NOT have the lock now.
app blocks on mymutex.lock()

Windows (with USE_CRITICAL_SECTION, default in svn):
-> trylock() returned 0.
-> we should have the lock now.
-> we got past the second lock.

Observations:
Linux: This is the default behaviour I would expect.

Windows (without USE_CRITICAL_SECTION): trylock should succeed, and does
if one looks at the code of Win32Mutex.cpp, but the return value of
trylock is wrong (considering what the OpenThreads header docs say).
Behaviour (apart from the return value) is what I would expect.

Windows (with USE_CRITICAL_SECTION): This is indeed a critical section
operator/thingy and not a mutex. Seems like blocking from the same
thread is ignored, it might work across threads I assume.

Now my questions:
Am I abusing mutexes? Should I not expect the Linux behaviour from Windows?
Is OSG not internally relying on the pthread behaviour? (I have not
investigated this in detail)

I feel that the library should present similar behaviour and if not, we
should at least document the differences.

regards
jp

PS. my test app is attached if anyone would like to try this themselves.





--
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.

CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html

CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html

For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
[EMAIL PROTECTED]


This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.  MailScanner thanks Transtec Computers for their 
support.


_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to