Understand, however scala also copy-on-write most of the time because list is immutable - http://www.artima.com/scalazine/articles/steps.html , I guess this may not as expensive as it seem?
I don't really "selling" this api, however, I feel it would be acceptable to give it a try, and see how it perform? On Tue, Dec 14, 2010 at 11:25 PM, Patricia Shanahan <[email protected]> wrote: > Carfield Yim wrote: >> >> Hi, copyonwritearraylist is suitable for this case imho. But it don't >> sound >> like an option to you. Would you share a bit more. I am interest to learn >> about it. > > My first feeling was that there is at least one workload that seems > plausible to me for which it would have poor performance. > > The workload is one in which most transactions are either a write or a > read-and-take. For example, consider a space that is the task pool for a > distributed workload. The writers are discovering tasks that need doing, > and recording them in the space. Each reader looks for a task it can do, > takes it from the space, and performs it. Now suppose the space is > buffering between bursty task creation and a fixed service rate. > > At times, the queue will get long, because of a burst of new tasks being > added. Once that happens, copy-on-write becomes expensive. > > Could people with more JavaSpaces experience comment on the plausibility > of this pattern? > > I believe JavaSpace needs to be treated as an infrastructure that needs > robust performance across a wide range of workloads, not just > optimization to make one workload run fast. However, I am tempted to > implement a CopyOnWriteArrayList version, and say that any other > implementation must beat it on at least one benchmark. > > Patricia >
