Return to Home
  View the contents of your Cart View cart  
  0 item(s) in cart  
  Checkout  

Gimpel Software - Discussion Forum
Discussion Forum
We invite you to use this forum to communicate with other PC-lint and FlexeLint users. You do not need to log in to post a message. WARNING: Your email address will not be encrypted. We recommend that you obfuscate it as protection from web crawlers. To receive technical support directly from Gimpel Software, please follow the guidelines at http://www.gimpel.com/html/support.htm
Reply Form
Original Message:
The reply from Gimpel (it didn't take this long
for Gimpel to send the reply, just for me to post
it here....)

Thanks for your report!  I was able to reproduce
the undesired Warnings and will forward this to
our resident thread expert for review.

The existence of the standard interface of
pthread_mutex_trylock(), it seems we really should
have support for this.

And we should probably have a separate name; e.g.
"thread_trylock".

Although it seems different systems may have
different ways of representing success.  E.g.
pthread_mutex_trylock() returns zero on success,
but your routine "my_lock" returns 1 on success
and zero on failure.  So it's not immediately
clear how we should spell the argument(s) to the
-sem() option.

-sem(my_lock,thread_lock_if_returns_one)

... seems like a bit of a mouthful.

FWIW, we're thinking of using spellings like this:

-sem(my_lock,thread_lock_1) // means:
 // my_lock() returns 1 if it succeeded in locking.

-sem(pthread_mutex_trylock,thread_lock_0) // means:
 // pthread_mutex_trylock() returns 0 if it
succeeded in locking.
Subject:
Name:
Email:
Message:
Please type the four digit number on the right: