Is there a way that Cppcheck checks the mutex locking / unlocking functionalities?
An example (with an error):
void foo() {
mutex_lock();
if (condition) { // condition is true
return;
}
mutex_unlock();
}
Is there a way Cppcheck can detect such a problem (the mutex stays locked)?
No, checking locking / unlocking functionalities is currently not supported.
It seems like you also asked the question in the Cppcheck forum where there is already feedback:
https://sourceforge.net/p/cppcheck/discussion/development/thread/a7b82c3e/
The best workaround that can currently be used is described in Daniel Marjamäki's answer:
https://sourceforge.net/p/cppcheck/discussion/development/thread/a7b82c3e/#f237
It suggests to use wrapper functions and the allocation / deallocation checks that are already supported by Cppcheck.
You can detect this error using the PVS-Studio analyzer. A V1020 diagnostic will be issued for this code: V1020 The function exited without calling the 'mutex_unlock' function. Check lines: 20, 18. test.cpp.
This is an empirical diagnostic which tries to figure out the way the code works based on functions names.
Related
In POSIX, there's the requirement that when a wait is called on a condition variable and a mutex, the 2 operations - unlocking the mutex and blocking the thread, be atomically performed, in such way that any broadcast/signal should take effect as if they happened after blocking. I suppose there should be equivalent requirements on C11, C++ condition variables as well, and I won't go on to do a verbose enumeration.
However, in some system (such as many people's nostalgia WinXP), there wasn't a condition variable mechanism. Instead, they have to perform a unlock+yield to achieve similar (same?) effect. And this works, because even if the broadcast/signal occured in-between the unlock and yield, when the thread is re-scheduled, its observable behavior is the same as if the wake occured after the block. WinXP supported mutex, and it had an SleepEx function that can work like an yield.
So it begs the question: What condition variables can do, that unlock+yield cannot?
In response to the comment: I use WinXP as an example because it happens to be one that supported mutex but not condvar, and the fact that it's one generation's memory. Of course, we assume correctness and reasonable performance, and the question doesn't specifically ask Windows and it asks any implementation in general.
According to the docs there is no reference of check panicking in any situation, but I would like to know if there is any edge case where this method could panic rather than returning false.
AFAICS, there are currently two cases where check() may fail:
The path leads to a cycle (see https://github.com/onflow/cadence/issues/2264)
Not sure: The code/type of the stored value is broken and cannot be loaded
Please feel free to open an issue in the Cadence repository if you think this should be changed, and especially why. Thanks!
In a Udacity's GCD course there was a small quiz:
let q = DispatchQueue.global(qos: .userInteractive)
q.async { () -> Void in
print("tic")
}
print("tac")
Which will be printed first?
The correct answer is: tac, then tic. Seems logical.
But, why is it so only when I create an Xcode project? In a playground it prints tic then tac. What am I missing?
In GCD
DispatchQueue.global(qos: .userInteractive).async{}
is below
DispatchQueue.main.async{}
Even thought it has quality of service (qos) as UI thread it does not means it is a main thread. So may be there is a difference in performance with play ground and ui project
please check apples documentation as well.
Apples documentation on GCD
key to your answer is in the question what really are you asking the "system" to do, an by system that is the whatever the code is running on the playground, your computer/phone or emulator. You are executing an asynchronous "block" of code - print("tic") with some priority ".userInteractive". If the system handles the asynchronous block first or continues with "normal" execution depends on priority and available resources. With asynchronous calls there is no real why to guarantee that it is executed before or after the code continues that is the nature of being asynchronous i.e execute the block as soon as the system allows it, all without blocking your current work. So the difference you are seeing in playground vs a project/emulator is that the project/phone/emulator must keep the UI/primary thread responsive so it continue with print("tac"), while the development playground favors the thread executing print("tic"). Bottom line is it has to deal with priority of execution and the available resources and how its implemented on the system you're running the code.
If I have a function call that returns true or false as the condition of an if statement, do I have to worry about Swift forking my code for efficiency?
For example,
if (resourceIsAvailable()) { //execute code }
If checking for the resource is computationally expensive, will Xcode wait or attempt to continue on with the code?
Is this worth using a completion handler?
What if the resource check must make a database call?
Good question.
First off... can a function be used? Absolutely.
Second... should it be used?
A lot of that depends on the implementation of the function. If the function is known (to the person who wrote it) to take a long time to complete then I would expect that person to deal with that accordingly.
Thankfully with a lot of iOS things like that are taken out of the hands of the developer (mostly). CoreData and Network requests normally come with a completion handler. So any function that uses them would also need to be async and have a completion handler.
There is no fixed rule for this. My best advice would be...
If you can see the implementation of the function then try to work out what it’s doing.
If you can’t then give it a go. You could even use the time profiler in Xcode profiler to determine how long it is taking to complete.
The worst that could happen is you find it is slow and then change it for something else.
I have 6 functions. I would like to execute 3 of these functions in the background (asynchronous?), in Xcode for Swift 2. Can you help me, how can I execute this 3 functions without a "freeze" in the UI? Thank you so much!
Martin R's comment is spot on, you should read Apple's concurrency programming guide. But here's one method you might use:
let queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)
dispatch_async(queue) {
doSomethingReallySlowAndTedious()
}
Be careful, though. It's especially easy to introduce bugs in your code by just copy-pasting concurrency code. Make sure you know what each function and parameter does.
(Also, consider the worst cases. Can the slow functions get stuck forever? What if the user wants to quit before the slow functions finish?)