By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,889 Members | 1,297 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,889 IT Pros & Developers. It's quick & easy.

Concurrency issues in reader-writer problem

P: n/a
Hi

I would like some ideas on way to solve the concurrency issue. The
problem is , I have an object say X which multiple readers need to
access and also to update. They do so by say two functions :
// simplistic view of the problem
Read()
{
return X;
}

Update(Y)
{
X= Y;
}

Now I would like to block any reader while calling update. With the
general solutions provided of having say a mutex and using it in Read
and Update would solve the problem. But then this would block multiple
readers also which is not desired. i.e a block on read should be
allowed only when update is called. Having a boolean and checkin is
not ideal as the atomicity of the operation is not guaranteed. Any
ideas on this?

Feb 21 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
On 21 Feb, 11:08, "Hunk" <santosh.udyav...@gmail.comwrote:
Hi

I would like some ideas on way to solve the concurrency issue. The
problem is , I have an object say X which multiple readers need to
access and also to update. They do so by say two functions :
// simplistic view of the problem
Read()
{
return X;

}

Update(Y)
{
X= Y;

}

Now I would like to block any reader while calling update. With the
general solutions provided of having say a mutex and using it in Read
and Update would solve the problem. But then this would block multiple
readers also which is not desired. i.e a block on read should be
allowed only when update is called. Having a boolean and checkin is
not ideal as the atomicity of the operation is not guaranteed. Any
ideas on this?
you nead reader-writer lock. the best implementation I've
seen is Valery Pryamikov's mrsw_guard

Feb 21 '07 #2

P: n/a
On Feb 21, 3:08 am, "Hunk" <santosh.udyav...@gmail.comwrote:
Hi

I would like some ideas on way to solve the concurrency issue. The
problem is , I have an object say X which multiple readers need to
access and also to update. They do so by say two functions :
// simplistic view of the problem
Read()
{
return X;

}

Update(Y)
{
X= Y;

}

Now I would like to block any reader while calling update. With the
general solutions provided of having say a mutex and using it in Read
and Update would solve the problem. But then this would block multiple
readers also which is not desired. i.e a block on read should be
allowed only when update is called. Having a boolean and checkin is
not ideal as the atomicity of the operation is not guaranteed. Any
ideas on this?
Is this a multi-threaded program? If it is, the best solution is to
use read-write locks in pthread library. See the manpage of
pthread_rwlock_wrlock and pthread_rwlock_rdlock. Note that you need to
have -DUSE_UNIX98 in your compiler flags.

Feb 21 '07 #3

P: n/a
On Feb 21, 7:55 pm, "Bharath" <cbku...@gmail.comwrote:
On Feb 21, 3:08 am, "Hunk" <santosh.udyav...@gmail.comwrote:


Hi
I would like some ideas on way to solve the concurrency issue. The
problem is , I have an object say X which multiple readers need to
access and also to update. They do so by say two functions :
// simplistic view of the problem
Read()
{
return X;
}
Update(Y)
{
X= Y;
}
Now I would like to block any reader while calling update. With the
general solutions provided of having say a mutex and using it in Read
and Update would solve the problem. But then this would block multiple
readers also which is not desired. i.e a block on read should be
allowed only when update is called. Having a boolean and checkin is
not ideal as the atomicity of the operation is not guaranteed. Any
ideas on this?

Is this a multi-threaded program? If it is, the best solution is to
use read-write locks in pthread library. See the manpage of
pthread_rwlock_wrlock and pthread_rwlock_rdlock. Note that you need to
have -DUSE_UNIX98 in your compiler flags.- Hide quoted text -

- Show quoted text -
Thanks... yes it is a multithreaded program. i'll take a look at the
reader writer locks mentioned. Any idea on how this is implemented in
zthreads?

Feb 22 '07 #4

P: n/a
On Feb 21, 9:59 pm, "Hunk" <santosh.udyav...@gmail.comwrote:
On Feb 21, 7:55 pm, "Bharath" <cbku...@gmail.comwrote:


On Feb 21, 3:08 am, "Hunk" <santosh.udyav...@gmail.comwrote:
Hi
I would like some ideas on way to solve the concurrency issue. The
problem is , I have an object say X which multiple readers need to
access and also to update. They do so by say two functions :
// simplistic view of the problem
Read()
{
return X;
}
Update(Y)
{
X= Y;
}
Now I would like to block any reader while calling update. With the
general solutions provided of having say a mutex and using it in Read
and Update would solve the problem. But then this would block multiple
readers also which is not desired. i.e a block on read should be
allowed only when update is called. Having a boolean and checkin is
not ideal as the atomicity of the operation is not guaranteed. Any
ideas on this?
Is this a multi-threaded program? If it is, the best solution is to
use read-write locks in pthread library. See the manpage of
pthread_rwlock_wrlock and pthread_rwlock_rdlock. Note that you need to
have -DUSE_UNIX98 in your compiler flags.- Hide quoted text -
- Show quoted text -

Thanks... yes it is a multithreaded program. i'll take a look at the
reader writer locks mentioned. Any idea on how this is implemented in
zthreads?- Hide quoted text -

- Show quoted text -
I never used zthreads but this link might help.
http://zthread.sourceforge.net/html/...WriteLock.html

Feb 22 '07 #5

P: n/a
"dasjotre" <da******@googlemail.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...
On 21 Feb, 11:08, "Hunk" <santosh.udyav...@gmail.comwrote:
[...]
you nead reader-writer lock. the best implementation I've
seen is Valery Pryamikov's mrsw_guard
how does it compare to the following algorithm:
Feb 23 '07 #6

P: n/a
DOH! sorry for the other msg... I left out the link!

"dasjotre" <da******@googlemail.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...
On 21 Feb, 11:08, "Hunk" <santosh.udyav...@gmail.comwrote:
[...]
you nead reader-writer lock. the best implementation I've
seen is Valery Pryamikov's mrsw_guard
how does it compare to the following algorithm:

http://groups.google.com/group/comp....fb0ed46a4bcb4b
Feb 23 '07 #7

P: n/a
"Hunk" <sa**************@gmail.comwrote in message
news:11*********************@t69g2000cwt.googlegro ups.com...
Hi

I would like some ideas on way to solve the concurrency issue.
Sure:

http://groups.google.com/group/comp....6ad37c34dd673a

http://groups.google.com/group/comp....fb0ed46a4bcb4b

http://appcore.home.comcast.net/
How about we transfer this thread over to comp.programming.threads before we
go any further?
Feb 23 '07 #8

P: n/a
A while back I was thinking about fully integrating a working solution to
the reader-writer problem directly into the C++ STL:

http://groups.google.com/group/comp....c9c2673682d4cf
Feb 23 '07 #9

P: n/a
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:PZ******************************@comcast.com. ..
DOH! sorry for the other msg... I left out the link!

"dasjotre" <da******@googlemail.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...
>On 21 Feb, 11:08, "Hunk" <santosh.udyav...@gmail.comwrote:
[...]
>you nead reader-writer lock. the best implementation I've
seen is Valery Pryamikov's mrsw_guard

how does it compare to the following algorithm:

http://groups.google.com/group/comp....fb0ed46a4bcb4b
Or this rw-spinlock implementation:

http://appcore.home.comcast.net/appc...k_algo1_c.html

http://appcore.home.comcast.net/appc...k_algo1_h.html
Feb 23 '07 #10

P: n/a
On Feb 23, 11:39 am, "Chris Thomasson" <cris...@comcast.netwrote:
A while back I was thinking about fully integrating a working solution to
the reader-writer problem directly into the C++ STL:

http://groups.google.com/group/comp....browse_frm/thr...
Hey chris , thanks a lot for the ton of information given. I'm just
browsing through it.. appears to be good. i'll just see if there's a
way to choose between the implementations.

Feb 23 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.