Found rosidl_default_generators: 1.0.1 (/opt/ros/foxy/share/rosidl_default_generators/cmake) Found action_msgs: 1.0.0 (/opt/ros/foxy/share/action_msgs/cmake) Found geometry_msgs: 2.0.4 (/opt/ros/foxy/share/geometry_msgs/cmake) Looking for pthread_create in pthread - found Looking for pthread_create in pthreads - not found Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed Performing Test CMAKE_HAVE_LIBC_PTHREAD Using RMW implementation 'rmw_fastrtps_cpp' as default Found rmw_implementation_cmake: 1.0.3 (/opt/ros/foxy/share/rmw_implementation_cmake/cmake) Using all available rosidl_typesupport_cpp: rosidl_typesupport_fastrtps_cpp rosidl_typesupport_introspection_cpp Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "1.1.1f") Found rosidl_adapter: 1.2.1 (/opt/ros/foxy/share/rosidl_adapter/cmake) Using all available rosidl_typesupport_c: rosidl_typesupport_fastrtps_c rosidl_typesupport_introspection_c Found rclcpp: 2.4.0 (/opt/ros/foxy/share/rclcpp/cmake) Using PYTHON_EXECUTABLE: /usr/bin/python3 Found PythonInterp: /usr/bin/python3 (found suitable version "3.8.10", minimum required is "3") Found ament_cmake: 0.9.9 (/opt/ros/foxy/share/ament_cmake/cmake) Check for working CXX compiler: /usr/bin/c++ - works Check for working CXX compiler: /usr/bin/c++
Check for working C compiler: /usr/bin/cc - works Check for working C compiler: /usr/bin/cc The CXX compiler identification is GNU 9.3.0 The C compiler identification is GNU 9.3.0 Output of colcon build -packages-select my_interfaces -event-handlers console_cohesion+ : user:~/ros2_ws$ colcon build -packages-select my_interfaces -event-handlers console_cohesion+ TL DR / Summary: It seems the ROSDS environment is missing pthreads in path /usr/bin/ld as stated in last part of CMakeError.log file There seems to be some issue with ROSDS environment, I believe, seems more like dependency requirement. I tried creating the exact same package in course environment and it works fine. I created my custom interfaces package but colcon build. This proves that the spinlock is more effective in term of CPU consumption and speed.I am currently working on the Course Project for ROS2 Basics in 5 Days - Python. However when used mutex, it took almost 8 seconds to complete. We can see that using spinlock, it took 2.5 seconds to complete the test. ~/lab/mutex-vs-spinlock -> g++ -DUSE_SPINLOCK -Wall -pthread Īs we can see, the picture is clear. ~/lab/mutex-vs-spinlock -> g++ -Wall -pthread
#CODEBLOCKS PTHREAD CODE#
Lets run the code and see how it performs, first with mutex and then with spinlock. The less time it took to run, the better. This difference is how we measure effectiveness. Once both threads are over, main() will measure the time again and print difference between two measurements. Each iteration of the loop it locks the mutex/spinlock and then unlocks it (lines 32-36 and 51-55). The thread, between lines 24 and 56, runs in a loop and pops entries from the list. Then it waits for both threads to finish their job. Finally, in lines 77-81 it measures current time and spawns two threads. Number of entries it will push into the list depends on LOOPS definition from line 10. main() starts with initialization of a mutex or a spinlock, in lines 67-71. Lets see how this little program works in greater detail. Printf("Consumer TID %lu\n", (unsigned long)gettid()) In any case, it will display number of seconds that has passed from the moment threads has been started, until they finish.
Since both threads work with the same list at the same time, list has to be protected with synchronization mechanism of some kind.ĭepending on whether the program has been compiled with USE_SPINLOCK or not, it will use a spinlock or a mutex to protect the list. It builds a list of integers and then starts two threads, each removing entries from the list. I’ll demonstrate a program that does the following. In this article I would like to demonstrate you how spinlocks are more efficient than mutexes. Apply your own judgment when considering using materials presented in this article for your needs. It does not mean that spinlocks are good for you. Spinlocks perform better than mutexes in this particular setup, on multi-processor computer. This is due to a nature of spinlocks, which I will describe in future posts.Īlso, it is not the intent of this article to show that spinlocks better than mutexes in all circumstances. Therefore, before I continue, I would like to make some things clear.īefore considering the code below, please note that spinlocks are totally useless on uni-processor computers.
#CODEBLOCKS PTHREAD UPDATE#
Update : On several occasions, commentators to this article pointed out that this post is somewhat incomplete.
0 kommentar(er)
