• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 385
  • Last Modified:

ReaderWriterLock .Net remoting

Hi

I have very high frequency updates with low frequency reads.  The speed of the reads is important so should in some way have a higher priority. The writes are very frequent but it is not so important that the resource is updated in a timely manner.  More important is that the reads requested by users are not waiting too long.

 Would a ReaderWriterLock be appropriate?

Is there a way to configure it so that reads would have priority over writes?
0
gustierng
Asked:
gustierng
  • 5
  • 4
1 Solution
 
Anurag ThakurTechnical ManagerCommented:
my suggstion will be to save the data in the memory and read it from memory instead of creating locks on the file as they might be locked up
my suggestion will include a singleton object on the remoting server which will be accessed by all the clients for writing or reading
0
 
gustierngAuthor Commented:
ok, I have a singleton on the remoting server using the approach you suggest.   The updating is a high frequency process (but the data update speed is of low priority).  More important is that user requests (reads) are handled quickly.  Is there a way to proritise the reads over the writes?
0
 
mastooCommented:
Doesn't the readerwriterlock do exactly what you want?  It processes reader requests with top priority other than it obviously can't interrupt a write that is in progress:

"Readers and writers are queued separately. When a thread releases the writer lock, all threads waiting in the reader queue at that instant are granted reader locks; when all of those reader locks have been released, the next thread waiting in the writer queue, if any, is granted the writer lock, and so on. In other words, ReaderWriterLock alternates between a collection of readers, and one writer."

0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
Anurag ThakurTechnical ManagerCommented:
for writing you will have one function and it will be queued and for reading you will have one funtion either you can queue or just allow any one to access any time
wont that serve the purpose
0
 
gustierngAuthor Commented:
On the write I use:
ThreadPool.QueUserWorkItem(new WaitCallback(RealTimeFunction),  objects);

On the read:
lock(this)
{
     value = GetValue(x);
}

Similar to what you say perhaps. This works ok with multiple users, but when the high frequency realtime updates are turned on, I start getting non-specific errors on the client:

Error message: RemotingException
An error occurred while processing the request on the server: Server encountered an internal error. To get more info turn on customErrors in the server's config file.

see:

http://www.experts-exchange.com/Programming/Languages/C_Sharp/Q_24162462.html
0
 
Anurag ThakurTechnical ManagerCommented:
what kind of remoting you are using tcp or http
and what kind of objects you are creating
may be in the scenario of higi frequency of call you might be running out of memory
0
 
gustierngAuthor Commented:
tcp

debugging this kind of thing is fairly new to me so any ideas / solutions / methodologies would be helpful.
0
 
Anurag ThakurTechnical ManagerCommented:
try to run your project without remoting configured
remoting is a hard thing to debug and the only option to debug if you can switch off remoting and just debug the project
0
 
gustierngAuthor Commented:
the errors i get seem to be connection errors on the client, so would not be able to hit the break points
0
 
gustierngAuthor Commented:
Referring to mastoo's comment

See: http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx

ReaderWriterLock is used to synchronize access to a resource. At any given time, it allows either concurrent read access for multiple threads, or write access for a single thread. In a situation where a resource is changed infrequently, a ReaderWriterLock provides better throughput than a simple one-at-a-time lock, such as Monitor.

This is the opposite of what I was after.  My resource changes frequently, but I need high priority read access.  I have tested the ReadWriterLock but does not perform well on the read side.  It takes about 1 minute to get to the lock.
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now