Where can I see the code? I dont see it in this thread. your link to http://groups.google.com/group/lock-free/files is giving me 404
On Monday, August 31, 2009 at 10:34:10 PM UTC+5:30, Dmitry Vyukov wrote: > > On Aug 27, 2:39 am, Sankar <shankar.n...@gmail.com> wrote: > > > Hmmm... Various parameters of the queue (producer block size, consumer > > > block size, algorithm used by get_item_idx()) may be tuned. I've just > > > tried to pick parameters that maximize throughput in my particular > > > environment. Currently I have no idea as to what parameters must be on > > > different machine or under different workload. > > > Still opened question is how and why they affect performance (why > > > current queue works better than my initial variant?). > > > Other than that I can't think of any other improvement now. I've tried > > > to incorporate everything I consider important. > > > > But how would you be able to tune these parameters( producer block > > size, consumer > > block size, algorithm used by get_item_idx() ) in a generic way to > > address all environments. > > Well, I don't know. Maybe they are equal for all environments :) > > > > Do you mean to say that you will be able to do that once you find the > > reason as to why > > your current queue works better than your initial variant? > > Maybe that will help, I don't know. > > > > > What exactly do you mean? New algorithms? > > > > Ya scalable synchronization algorithms( where u see lot of scope > > for improvements) where I can put my head > > and learn more(and probably use what I have learned til now) to come > > out with something new. > > > IMHO, the most difficult and still unsolved is the problem of safe > memory reclamation (or deferred reclamation or garbage collection) for > native C/C++ environment. > I mean algorithms like SMR (safe memory reclamation), RCU (read copy > update), ROP (repeat offender problem), atomic reference counting, > proxy collector, SMR+RCU, VZOOM, etc. > However all of them have serious limitations (like work only in kernel > space, or handle only limited number of objects per thread, of have > big overheads, or require special periodic activity of all threads, or > not enough prompt, etc). > > > > -- > Dmitriy V'jukov -- --- You received this message because you are subscribed to the Google Groups "Scalable Synchronization Algorithms" group. To unsubscribe from this group and stop receiving emails from it, send an email to lock-free+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/lock-free/c24e9ef1-5481-4c1a-b606-691833d28bfa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
