search

VincentWei / MiniGUI

A modern and mature cross-platform window system for embedded systems and smart IoT devices.
http://www.minigui.com
GNU General Public License v3.0
695 stars 157 forks source link

Issue about ucos2_pthread #74

Open KevinShuuichi opened 3 years ago

KevinShuuichi commented 3 years ago

Hi, Mr.Vincent: I used ucos2_pthread to perform some multi-thread tasks. The miniGui version is 3.2.2. I created a thread using pthread_create(&threadID, 0, subThreadCallBack, NULL), and I put a pthread_exit(0) at the last of subThreadCallBack. In the main thread, I used pthread_join to wait the subThread to be finished. I found the pthread_join is useless. So, I debuged the code in ucos2_pthread.c. There're something strange.

  1. In the function of pthread_info_id: we don't need to calculate the index, the id is exactly the offset of thread_table, because the thread id you created in pthread_create is set to nthread - thread_table.

  2. In the function of pthread_join: if the pthread_join( ) is performed first, it locks the pthread_mutex, then if the state is running , it will go to OSSemPend(joinee->joiner, 0, &ucos2_err) to wait subThread to exit. But in the pthread_exit(), it locks the pthread_mutex again, it's a dead lock. These two thread is running forerver. So I think it should unlock before pthread_join goes to OSSemPend.

  3. In the function of pthread_exit: OSSemPost(self->joiner) only happens when nr_joined is greater than 0, but before the OSSemPend in pthread_join, there is no code to add 1 to nr_joined, so it can't post the sem. pthread_join is locked forever. These are some issues I have found by now. Or maybe it's just my misuse. Looking forward to your reply.

VincentWei commented 3 years ago

I think your analysis is correct. There are some bugs in the implementation.

However, we have no dev. environment to fix or test the change. I think you can try to fix them and send us a PR.

Thanks in advance.