> On Jul 18, 2018, at 7:34 PM, wubenq...@ruijie.com.cn wrote: > > Hi~ > > If the lthreads run on different lcores, a race condition with lthread_mutex > may occur. > Like this: > lthread1 run on lcore=1 > lthread2 run on lcore=2 > If the mutex is owned by lthread2, lthread1 try to lock the mutex that will > block thread1. lthread_sched on lcore1 will insert lthread1 to the blocked > queue of the mutex. lthread1 blocks until lthread2 unlock the mutex. > Is that right? > > Let's go back to the previous question. > > Refer to > http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_wait.html > "The pthread_cond_wait() and pthread_cond_timedwait() functions are used to > block on a condition variable. They are called with mutex locked by the > calling thread or undefined behaviour will result. > These functions atomically release mutex and cause the calling thread to > block on the condition variable cond; atomically here means "atomically with > respect to access by another thread to the mutex and then the condition > variable”."
Yes, I believe you are correct. I was able to look at my version of lthreads and I had changed lthread_cond_wait() to have a mutex argument and removed the reserved variable. The same was done for timed wait function. As I remember I found a couple minor problems in lthreads, which I fixed. The problem is my lthread code is somewhat different then the code in DPDK and my changes would not apply to DPDK lthreads. > > So I think there is a problem with pthread_cond_wait implemented by lthread. > If that is the case, could lthread fix this problem? > > Regards, > Wubenqing > > > From: Wiles, Keith > Date: 2018-07-18 23:01 > To: 吴本卿(研五 福州) > CC: dev@dpdk.org > Subject: Re: [dpdk-dev] Does lthread_cond_wait need a mutex? > > > > On Jul 17, 2018, at 10:43 PM, wubenq...@ruijie.com.cn wrote: > > > > Hi~ > > Reference: > > http://doc.dpdk.org/guides-18.05/sample_app_ug/performance_thread.html?highlight=lthread > > The L-thread subsystem provides a set of functions that are logically > > equivalent to the corresponding functions offered by the POSIX pthread > > library. > > I think there is a bug with pthread_cond_wait of lthread implement. > > Look at this code, there are two lthread: > > > > lthread1: > > pthread_mutex_lock(mutex); //a1 > > if (predicate == FALSE) { //a2 > > pthread_cond_wait(cond, mutex) //a3 > > } > > pthread_mutex_unlock(mutex); //a4 > > > > int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex) > > { > > if (override) { > > pthread_mutex_unlock(mutex); //a31 > > int rv = lthread_cond_wait(*(struct lthread_cond **)cond, 0); //a32 > > > > pthread_mutex_lock(mutex); //a33 > > return rv; > > } > > return _sys_pthread_funcs.f_pthread_cond_wait(cond, mutex); > > } > > > > lthread2: > > pthread_mutex_lock(mutex); //b1 > > predicate = TRUE; //b2 > > pthread_mutex_unlock(mutex); //b3 > > pthread_cond_signal(cond); //b4 > > > > > > If the sequence is: > > a1->a2->a31->b1->b2->b3->b4->a32 > > Will lthread1 sleep forever? > > Maybe is it possible, my brain is not working this morning. Please remember > that lthreads must give up control or lthread will continue to and can not be > preempted. > > Does that fix the problem? > > > > > ________________________________ > > 吴本卿(研五 福州) > > Regards, > Keith Regards, Keith
