I have been reading things like this:
The first definition you refer to is part of the kernel lock validator, aka "lockdep".
I'm a kernel newbie and what bothers me is why the kernel lock validator called "lockdep"?
Does the "dep" stand for dependency? Please correct me if I'm wrong, thanks!
Because the kernel lock validator checks a lot of lock depedancy inside the kernel so it is also called 'lockdep'.
Related
About Critical Section Controller:
The Critical Section Controller ensures that its children elements (samplers/controllers, etc.) will be executed by only one thread as a named lock will be taken before executing children of controller.
It's not that hard to create a dead lock and make JMeter stuck
If inside lock A add lock B and inside other lock B add lock A with a few threads there's a dead lock:
Can this be avoided ? and if not can there be a warning for users using this controller ?
Yes indeed using, the way you show it can lead to Java Dead Lock as it's the equivalent of a "synchronized" block in Java.
As JMeter provides a kind of algorithmic way to develop a test, this looks regular to me.
You can potentially raise an enhancement request for detection of Dead lock or provide a PR improving documentation.
I think project will be happy to merge it.
Can I have an boost::promise<void> created in a thread and set its value in another different thread through boost::promise<void>::set_value().
I think I am having a crash because of this, probably, so I must guess that no, but I would need confirmation. Thanks in advance.
P.S.: Note that I am using boost implementation.
Yes, you can do that, but you must ensure that the call to set_value() does not conflict with anything in the other thread, such as the completion of the constructor or the start of the destructor.
(According to the C++ standard you cannot even make potentially concurrent calls to set_value() and get_future() but that is a defect and should get fixed.)
To give a more precise answer it would be necessary to see exactly what your code is doing.
I'm new to kernel and driver programming, so i hope my question is not too simple.
I'm working with a madwifi driver, in order to add some functionalities of my own. In my code i added some variables and structures that need to be initialized before the actual code starts.
While working i have encountered the following question:
where is the best place to put the functions that in charge of initializing this variables/structures?
As far as i know, there is a special macro *module_init* which is being executed upon loading the module to the kernel, however, i could not find it in the madwifi driver code. What i have found instead is another famous macro, the *exit_module* though.
so my questions are:
Is it recommended to add an init_module and do all my initializations there?
Is it recommended to use the exit_module to free the allocated memory?
Thanks for the help!
Omer
Every module (driver) defines two functions, one to be invoked when the module is loaded into the kernel and one for when the module is removed.
module_init() and module_exit() are the two special kernel macros to declare two functions for these roles.
I suppose your driver has init function. init() functions are generally used to initialize or register your driver.
Also check for the probe() function. If your driver can support multiple devices, once driver is registered, kernel calls probe() once for each device. This probe function starts the per-device initialization: initializing hardware, allocating resources, and registering the device with the kernel as a block or network device or whatever it is.
As I said in my comment, the initialization code can be in the init_module function.
Regarding your questions:
The module initialization function (init_module) is the right
place for driver-level initialization. It's recommended to use it,
unless your needs are trivial enough for C static variable
initialization.
The cleanup function (cleanup_module) must make
sure that the driver has released any resource it has allocated.
It's the right place to free anything allocated during
initialization.
I'm writing a linux driver and I would like to register a callback function to be invoked when the system goes to sleep. What is the api to do this?
Thanks.
It depends on what kind of driver you have. For example, if you have a driver that is registered with platform_device_register(), then the struct platform_driver includes a .suspend member for the device's suspend callback. With PCI devices, the struct pci_driver that you pass to pci_register_driver() similarly includes a .suspend member.
Most device classes should provide a similar mechanism.
I'm pretty sure you want acpi_install_fixed_event_handler(), found in acpi/acpi.h , the generic events found in acpi/actypes.h (which is included from acpi.h).
The second argument to acpi_install_fixed_event() wants a handler of type u32, with the last argument being a void *context. What I could not find is a list of possibilities that *context might be. However, it looks like you just something to be entered on events, which means you probably don't care about the context. Not quite a callback, but the same result.
If you register a fixed handler for (say, ACPI_EVENT_POWER_BUTTON or ACPI_EVENT_SLEEP_BUTTON), your handler should be entered on the respective event. I'm not 100% sure ACPI_EVENT_SLEEP_BUTTON is what you want, i.e. I can't quite tell if its the same event as the system going to sleep on its own. Testing and further investigation is, of course, and exercise for the reader.
An example of using it can be found in drivers/rtc/rtc-cmos.c.
Please take care to wrap any code from acpi.h in
#ifdef CONFIG_ACPI
....
#endif /* CONFIG_ACPI */
I could be completely wrong here, I have not actually needed to do this for any of the drivers that I've written. The above is the result of about 30 minutes of digging through the source of 2.6.32.8 , which may be completely different than the kernel you are working with.
Please leave a comment if I am way off base :) I think this is what you are looking for.
Additional
As for licensing, its exported:
drivers/acpi/acpica/evxface.c:ACPI_EXPORT_SYMBOL(acpi_install_fixed_event_handler)
Not
*_EXPORT_SYMBOL_GPL()
... So you should have no issues using it, whatever you happen to be doing.
Finally, this is a perfectly good question that would probably be met with a good reception on the Linux Kernel mailing list. If in doubt, ask there. Even if this 'just works', its a good idea to confirm it.
The solution I settled on was using notifier chains. On later versions of the kernel you can register with register_pm_notifier. If your kernel doesn't support that api you can use the notifier for cpu hot-plug events (this appears to be what KVM uses). On the way in and out of suspend the cpu hotplug notifier chain fires.
The ACPI Howto probably will give you a good headstart...
I'm encountering the following error at unpredictable times in a linux-based (arm) communications application:
pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Google turns up a lot of references to that error, but little information that seems relevant to my situation. I was wondering if anyone can give me some ideas about how to troubleshoot this error. Does anyone know of a common cause for this assertion?
Thanks in advance.
Rock solid for 4 days straight. I'm declaring victory on this one. The answer is "stupid user error" (see comments above). A mutex should only be unlocked by the thread that locked it. Thanks for bearing with me.
TLDR: Make sure you are not locking a mutex that has been destroyed / hasn't been initialized.
Although the OP has his answer, I thought I would share my issue in case anyone else has the same problem I did.
Notice that the assertion is in __pthread_mutex_lock and not in the unlock. This, to me, suggests that most other people having this issue are not unlocking a mutex in a different thread than the one that locked it; they are just locking a mutex that has been destroyed.
For me, I had a class (Let's call it Foo) that registered a static callback function with some other class (Let's call it Bar). The callback was being passed a reference to Foo and would occasionally lock/unlock a mutex that was a member of Foo.
This problem occurred after the Foo instance was destroyed while the Bar instance was still using the callback. The callback was being passed a reference to an object that no longer existed and, therefore, was calling __pthread_mutex_lock on garbage memory.
Note, I was using C++11's std::mutex and std::lock_guard<std::mutex>, but, since I was on Linux, the problem was exactly the same.
I was faced with the same problem and google sent me here. The problem with my program was that in some situations I was not initializing the mutex before locking it.
Although the statement in the accepted answer is legitimate, I think it is not the cause of this failed assertion. Because the error is reported on pthread_mutex_lock (and not unlock).
Also, as always, it is more likely that the error is in the programmers source code rather than the compiler.
The quick bit of Googling I've done often blames this on a compiler mis-optimization. A decent summation is here. It might be worth looking at the assembly output to see if gcc is producing the right code.
Either that or you are managing to stomp on the memory used by the pthread library... those sort of problems are rather tricky to find.
I was having same problem
in my case inside the thread i was connecting vertica db with odbc
adding following setting to /etc/odbcinst.ini solved my problem. dont geting the exception so far.
[ODBC]
Threading = 1
credits to : hynek
I have just fought my way through this one and thought it might help others.
In my case the issue occured in a very simple method that locked the mutex, checked a shared variable and then returned.
The method is an override of the base class which creates a worker thread.
The problem in this instance was that the base class was creating the thread in the constructor. The thread then started executing and the derived classes implementation of the method was called. Unfortunately the derived class had not yet completed constructing and the mutex in the derived class had uninitialised data as the mutex owner. This made it look like it was actually locked when it wasn't.
The solution is really simple. Add a protected method to the base class called StartThread(). This needs to be called in the derived classes constructor, not from the base class.
In case you are using C++ and std::unique_lock, check this answer: https://stackoverflow.com/a/9240466/9057530
adding Threading=0 in /etc/odbcinst.ini file fixed this issue