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
Gimpel Software - Discussion Forum
Subject From Date & Time
Undeserved 454 and 456 Marcel Versteeg July 04, 2011
4:31:14 AM
  Re: Undeserved 454 and 456 Luca July 04, 2011
8:38:08 AM
          Re: Undeserved 454 and 456 Marcel Versteeg August 30, 2011
7:58:18 AM
                  Re: Undeserved 454 and 456 Don Burn October 15, 2012
1:43:48 PM
                  Re: Undeserved 454 and 456 Michael Hordijk June 07, 2013
12:46:48 PM
                          Re: Undeserved 454 and 456 Kurt September 25, 2015
8:41:42 PM
 
Subject: Undeserved 454 and 456
Date: July 04, 2011
4:31:14 AM
Name: Marcel Versteeg
Email: marcel.versteeg@nl.bosch.com
Message:
I our software we have a mutex wrapper object 
(intended to be implemented on different OS) 
that indicates whether a mutex take was 
successful, by returning a bool on the Take 
method.
In case the Take was successful, the guarded 
actions are performed and the mutex is released 
by calling the Release method on the mutex 
object. In case the Take was not successful, the 
mutex Release method will not be called (to 
prevent a disbalance between the take and 
release.

However when I Lint the code, I get errors 454 
and 456. The example here (as can be entered in 
the online demo) triggers the issue.

----------- CODE START --------------
//lint -sem(my_lock, thread_lock)
//lint -sem(my_unlock, thread_unlock)

bool my_lock()
{
    return true;
}

void my_unlock()
{
}

int main()
{
    if (my_lock())
    {
        // do something interesting
        my_unlock();
    }
}
----------- CODE END --------------

When I change the signature of the my_lock 
function to return void, the errors 454 and 456 
disappear, and they also disappear when the 
my_unlock() call is moved outside of the if-
statement.

I do believe the above code is correct and the 
messages 454 and 456 are undeserved.
Reply to this Message! Previous Message Next Message
 
Subject: Re: Undeserved 454 and 456
Date: July 04, 2011
8:38:08 AM
Name: Luca
Message:
Your function "lock" wants to be a
"pthread_mutex_lock", while its usage is that one
of "pthread_mutex_trylock", that is is not
supported by FlexeLint.
An enhancement request should be done to support.

I'm interested in this, please reports here with
the Gimpel replay.
Reply to this Message! Previous Message Next Message
 
Subject: Re: Undeserved 454 and 456
Date: August 30, 2011
7:58:18 AM
Name: Marcel Versteeg
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.
Reply to this Message! Previous Message Next Message
 
Subject: Re: Undeserved 454 and 456
Date: October 15, 2012
1:43:48 PM
Name: Don Burn
Email: burn@windrvr.com
Message:
I hope Gimpel will consider making the trylock 
approach an expression, for that matter the same 
is needed for many regular mutex API's that 
return a success or failure.  

As someone who has had to deal with locking for 
over 40 years, I also hope Gimpel will consider 
tracking the "lock" that is acquired.  I have 
found more Lock(a)....Unlock(b) errors than 
forgetting the locks in the first place.
Reply to this Message! Previous Message Next Message
 
Subject: Re: Undeserved 454 and 456
Date: June 07, 2013
12:46:48 PM
Name: Michael Hordijk
Email: hoffbrinkle@hotmail.com
Message:
What about allowing thread_trylock (or just
thread_lock) to be used in an expression. 
Something like this:

-sem( pthread_mutex_trylock, @n == 1 || thread_lock )

or, maybe more slightly more accurate:

-sem( pthread_mutex_trylock, @n == 0 && thread_lock )

Reply to this Message! Previous Message Next Message
 
Subject: Re: Undeserved 454 and 456
Date: September 25, 2015
8:41:42 PM
Name: Kurt
Message:
This is a recurring issue for me.  I've requested
the feature here:
http://support.gimpel.com/forums/225702-general/suggestions/7207148-add-support-for-pthread-mutex-trylock-semantics
and referenced this thread.

Please go there and vote it up.
Reply to this Message! Previous Message Next Message