Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #2107 > unrolled thread

About Distributed Reader-Writer Mutex by Dmitry Vyukov

Started by"aminer" <aminer@videotron.ca>
First post2012-08-25 19:47 -0500
Last post2012-08-25 20:01 -0500
Articles 2 — 1 participant

Back to article view | Back to comp.programming


Contents

  About Distributed Reader-Writer Mutex by Dmitry Vyukov "aminer" <aminer@videotron.ca> - 2012-08-25 19:47 -0500
    Re: About Distributed Reader-Writer Mutex by Dmitry Vyukov "aminer" <aminer@videotron.ca> - 2012-08-25 20:01 -0500

#2107 — About Distributed Reader-Writer Mutex by Dmitry Vyukov

From"aminer" <aminer@videotron.ca>
Date2012-08-25 19:47 -0500
SubjectAbout Distributed Reader-Writer Mutex by Dmitry Vyukov
Message-ID<k1bo6h$m94$1@dont-email.me>
Hello,

 Dmitry Vyukov  wrote this:

"In order to a reader-writer mutex to scale reader's time under mutex must
be significant, on the order of, let's say, 10'000 cycles. And the more 
hardware
threads you have the longer the time must be. Otherwise, inter-reader 
synchronization
overheads dominate, and the system does not scale."

Read here:

http://www.1024cores.net/home/lock-free-algorithms/reader-writer-problem/distributed-reader-writer-mutex


I have done some tests with my light weight MREW and my lockfree mpmc
fifo queue and what i think is that the CAS is generating a lot of 
contention this is is why
my rwlock is not scaling.

What you are doing Dmitry Vyukovin in your distributed rwlock is lowering 
the contention
using the same method as lock striping it is why it is scaling, but there is 
still a possibility
of contention that can cause a problem to the scalability if you are not 
setting the number
of rwlocks inside your distributed rwlock correctly.


other than that:

I have looked at the Distributed Reader-Writer Mutex by Dmitry Vyukov, look
at it here:"

http://www.1024cores.net/home/lock-free-algorithms/reader-writer-problem/distributed-reader-writer-mutex


and i think there is a problem with this method,  cause look at the write
lock function:


int         distr_rw_mutex_wrlock(distr_rw_mutex_t* mtx)
{
    int                     i;
    for (i = 0; i != mtx->proc_count; i += 1)
        pthread_rwlock_wrlock(&mtx->cell[i].mtx);
    return 0;
}


What is wrong with it ? suppose two or more writers want to lock this
distributed rwlock there is a possibility of a deadlock.

So i think you have to use a critical section around the for loop to be able
to lock all the rwlocks atomically to avoid the deadlock problem..




Thank you,
Amine Moulay Ramdane.












[toc] | [next] | [standalone]


#2110

From"aminer" <aminer@videotron.ca>
Date2012-08-25 20:01 -0500
Message-ID<k1bp1a$qcc$1@dont-email.me>
In reply to#2107
Patricia Shanahan wrote:
> The text explanation on the referenced web page says 'No additional
> synchronization between writers is required, writers acquire the mutexes
> in the same order (from 0 to P-1), so ownership over mutex 0 basically
> determines who is the "current" writer (all other potential writers are
> parked on mutex 0).'



You are absolutly right.


Thank you,
Amine Moulay Ramdane.


"aminer" <aminer@videotron.ca> wrote in message 
news:k1bo6h$m94$1@dont-email.me...
>
> Hello,
>
> Dmitry Vyukov  wrote this:
>
> "In order to a reader-writer mutex to scale reader's time under mutex must
> be significant, on the order of, let's say, 10'000 cycles. And the more 
> hardware
> threads you have the longer the time must be. Otherwise, inter-reader 
> synchronization
> overheads dominate, and the system does not scale."
>
> Read here:
>
> http://www.1024cores.net/home/lock-free-algorithms/reader-writer-problem/distributed-reader-writer-mutex
>
>
> I have done some tests with my light weight MREW and my lockfree mpmc
> fifo queue and what i think is that the CAS is generating a lot of 
> contention this is is why
> my rwlock is not scaling.
>
> What you are doing Dmitry Vyukovin in your distributed rwlock is lowering 
> the contention
> using the same method as lock striping it is why it is scaling, but there 
> is still a possibility
> of contention that can cause a problem to the scalability if you are not 
> setting the number
> of rwlocks inside your distributed rwlock correctly.
>
>
> other than that:
>
> I have looked at the Distributed Reader-Writer Mutex by Dmitry Vyukov, 
> look
> at it here:"
>
> http://www.1024cores.net/home/lock-free-algorithms/reader-writer-problem/distributed-reader-writer-mutex
>
>
> and i think there is a problem with this method,  cause look at the write
> lock function:
>
>
> int         distr_rw_mutex_wrlock(distr_rw_mutex_t* mtx)
> {
>    int                     i;
>    for (i = 0; i != mtx->proc_count; i += 1)
>        pthread_rwlock_wrlock(&mtx->cell[i].mtx);
>    return 0;
> }
>
>
> What is wrong with it ? suppose two or more writers want to lock this
> distributed rwlock there is a possibility of a deadlock.
>
> So i think you have to use a critical section around the for loop to be 
> able
> to lock all the rwlocks atomically to avoid the deadlock problem..
>
>
>
>
> Thank you,
> Amine Moulay Ramdane.
>
>
>
>
>
>
>
>
>
>
>
>
> 

[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming


csiph-web