On Tuesday, December 2, 2014 4:59:39 AM UTC+1, Ashish wrote:
>
>
> Any updates on this please? I investigated it little further and realized 
> libuv relies on only Critical Section objects to synchronize threads.
> I suspect there are problems with that approach.
>
> Now if we use read and write locks as demonstrated in the code below, what 
> happens is, a thread enters in a critical section then another thread is 
> very likely to go ahead of it and call leave critical section.
>
> As per Microsoft's documentation, 
> "If a thread calls *LeaveCriticalSection* when it does not have ownership 
> of the specified critical section object, an error occurs that may cause 
> another thread using *EnterCriticalSection* 
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms682608(v=vs.85).aspx>
>  to wait indefinitely."
>
>
> On Sunday, November 30, 2014 1:05:29 AM UTC+5:30, Ashish wrote:
>>
>>
>> This little piece of code should keep running forever without any 
>> trouble. However, when I ran it at my end it results in deadlock situation.
>> I apparently can't see any reason for deadlock. Please can someone have a 
>> quick look to ensure I am not doing anything in wrong order here.
>> (This is on Windows XP. I am using libuv-v1.0.0. Also, I've set 
>> threadpool size to 31 before running the code)
>>
>>
>> #include <uv.h>
>>
>> uv_work_t gWorkT[31];
>> uv_rwlock_t g_rwlLock;
>> void rd_wr_locks_in_thread(uv_work_t* work_t)
>> {
>>     static int value = 0;
>>     while(1)
>>     {
>>         uv_rwlock_rdlock(&g_rwlLock);
>>         BOOL isvalueodd = value % 2;
>>         uv_rwlock_rdunlock(&g_rwlLock);
>>
>>         uv_rwlock_wrlock(&g_rwlLock);
>>         value ++;
>>         uv_rwlock_wrunlock(&g_rwlLock);
>>     }
>> }
>>
>> void after_rd_wr_locks_in_thread(uv_work_t* work_t, int status)
>> {
>> }
>>
>> int main()
>> {
>>     loop = uv_default_loop();
>>
>>     int retval = uv_rwlock_init(&g_rwlLock);
>>     if (retval < 0)
>>     {
>>         printf("\nError initilizing lock");
>>         return -1;
>>     }
>>
>>     for (int i=0; i<31; i++)
>>     {
>>         int RetVal = uv_queue_work(loop, &gWorkT[i], 
>> rd_wr_locks_in_thread, after_rd_wr_locks_in_thread);
>>     }
>>     return uv_run(loop, UV_RUN_DEFAULT);
>>
>> }
>>
>>

You're right - the xp/2k3 "fallback" implementation of read-write locks 
seems broken. A patch would be welcome. 

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to