From: Erwin Abbott Date: 2007-05-31T17:31:53+09:00 Subject: Re: DRb and Thread safety On 5/31/07, Brian Candler wrote: > There's some examples which do this at > http://wiki.rubygarden.org/Ruby/page/show/DRbTutorial > > Unfortunately Rubygarden is down more often than it's up (it's down as I > write this), but you can get a cached version through Google. Glad you mentioned the Google cache... I kept finding links to that page and wondered what I was missing. I'll be reading that next. > Well, that's the general locking problem in a nutshell, and many books have > been written about this :-) I'm very interested in a book on programming with threads, any recommendations? I'll probably browse the bookstore this weekend. I'm afraid everything will be focused on specifics like language/OS rather than general concepts. It's also hard to know what's good from reading reviews on Amazon. > The solution will be domain-specific. The simplest solution is to serialise > all requests on the server side using a global mutex: > > This is a reasonable approach if all the actions like add, search are > CPU-bound, because having concurrency here won't gain you anything. The reason for using synchronization in #search is because we might start in the middle of a #write call from another thread, right? I had something in mind like an SQL database which would search using the "not-yet-written" version of the data... but now I think I see that's quite complicated. I also think I just came to a realization. In the threading examples I've seen, there's typically a "sleep 5" as a placeholder for some big computation. But this simulates an I/O bound process instead of something computationally intesive. So processing 10 items each with their own thread (which just sleeps for 5 seconds) will finish in close to 5 seconds... a huge improvement over processing them serially. But processing the items was actually CPU intensive, would it be more like 50 seconds? > If some of these actions can block on external I/O, then you might want to > have more concurrency. So you can look at having a shared read lock / > exclusive write lock kind of model; ... I'd like to learn the design concepts involved with that, just to gain an appreciation for the complexity of it. Is my best bet to look at the source code of something like an SQL server? Maybe one of the Berkeley DB variants or SQLite would be a good starting point (or maybe a multiuser DB if these aren't multithreaded). Thanks for your help! Erwin