Contact the apache river folks for details. There have been several
published accounts, but it is definitely the case that many jini/javaspaces
users felt it was in their own interest not to draw attention to this
technology as it was determined to be a competitive advantage.
http://river.apach
I've used javaspaces a fair bit in high-flexibility situations, although
not in a truly high-scale situation. I am aware of truly high-scale
implementations. Just be careful extrapolating from one case to another.
Contact the apache river folks for detailed reports of javaspaces in
high-scale..
> When you choose an atom you are effectively saying that nobody else will
> ever need to ensure consistency between this identity and another. This is
> fine if you're writing an application, where you can stake a claim and
> create an atom for global state, but what when a library you use d
On 14 Dec 2012, at 13:52, Rich Hickey wrote:
> On Dec 14, 2012, at 12:55 AM, Paul Butcher wrote:
>> Rich - what is the "soundbite description" of Clojure's concurrency model
>> you're happiest with?
>
> Ah, soundbites, the foundation of modern programmer education :)
Maybe I should have said "l
On Dec 14, 2012, at 12:55 AM, Paul Butcher wrote:
> On 14 Dec 2012, at 00:30, kovas boguta wrote:
>
>> My recommendation is either "Persistent Datastructures" or "Database as a
>> Value"
>
> Interesting. I'd be interested to hear others thoughts on this. In particular
> Rich's
>
> Rich - wh
> In the epic thread about the STM between Rich and Cliff Click[1] the
> main argument against the STM was that it didn't help solve the problem
> of where to place guards around the data. From one of Cliff's arguments:
>
> In a trivial example I can say �go up one call level and atomic
> t
On Fri, Dec 14, 2012 at 12:55 AM, Paul Butcher wrote:
> On 14 Dec 2012, at 00:30, kovas boguta wrote:
> If you can't incorporate novelty without cloning the
> entire datastructure, thats not that useful.
>
>
> I'm not 100% sure what you mean by this - can you expand?
The principle failing of lo
I don't really care where good ideas come from. Feel free to expand your
mind.
2012年12月14日金曜日 6時58分54秒 UTC+9 raould:
>
> > the design of Apache CouchDB's Multi-Version Concurrency Model.
>
> because haskell got it from apache, i'm sure ;-)
>
--
You received this message because you are subscr
On 14 Dec 2012, at 00:30, kovas boguta wrote:
> My recommendation is either "Persistent Datastructures" or "Database as a
> Value"
Interesting. I'd be interested to hear others thoughts on this. In particular
Rich's
Rich - what is the "soundbite description" of Clojure's concurrency model
yo
On 14 Dec 2012, at 00:22, Patrick Logan wrote:
> Another concurrency model I've used a great deal is the tuplespace model,
> specifically javaspaces. This is an often forgotten model that has a lot to
> offer with a high expressiveness to complexity ratio.
Ah! That brings back memories :-) I
On 12 December 2012 16:21, Warren Lynn wrote:
> Although I am convinced that STM can solve things that locks cannot (See
> the claim "*lock-based programs do not compose" *on Wikipedia page
> http://en.wikipedia.org/wiki/Software_transactional_memory), I feel this
> feature is so much over-sold.
> Another concurrency model I've used a great deal is the tuplespace model,
> specifically javaspaces. This is an often forgotten model that has a lot to
> offer with a high expressiveness to complexity ratio.
otish:
in the back of my mind i seem to recall hearing that tuplespaces
sounded nifty
My recommendation is either "Persistent Datastructures" or "Database as a Value"
Its shocking and amazing that an entire database (eg, the most
concurrent stateful thing you can imagine) requires just a handful of
atoms. Check out
http://www.infoq.com/presentations/Datomic-Database-Value
Persiste
Paul,
Another concurrency model I've used a great deal is the tuplespace model,
specifically javaspaces. This is an often forgotten model that has a lot to
offer with a high expressiveness to complexity ratio.
Not closure specific, so feel free to contact me again directly if you're
interested
To add to the conversation, I wrote an agent-based website load tester
earlier this year for work. Happy to share my thoughts with Paul
offline if he thinks it's useful, although I wouldn't be able to share
the code itself.
On Dec 11, 2:25 am, Marko Topolnik wrote:
> To give the full story, I sho
> the design of Apache CouchDB's Multi-Version Concurrency Model.
because haskell got it from apache, i'm sure ;-)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new
Datomic stores the entire database in an atom (not an STM ref), and
updates it with a call to swap! It is literally no more complex than a
trivial hackneyed book example. :-)
A lot of my systems have evolved into something similar and I've
wondered what the implications of this approach ar
@Paul Butcher
I would argue that Clojure's STM implementation is very similar or based on
the design of Apache CouchDB's Multi-Version Concurrency Model.
1. Immutable by default.
2. You can't corrupt a completed transaction.
3. Conflict resolution essentially gives the previous revision before t
Hey Stuart,
Thanks for the response.
What I'm trying to do is keep each chapter focussed on an approach, rather than
a language. For example, in the chapter on Actors, I'll be showing examples in
Scala, but the discussion won't be (I hope!) particularly Scala-specific. I
hope to leave the read
On Wednesday, December 12, 2012 4:46:06 AM UTC-5, Marko Topolnik wrote:
>
> I wouldn't say that it should not have been added since its presence isn't
> harming anything. You could say, though, that rarely anyone would realize
> something was missing if Clojure didn't have the STM.
>
>
>
Alth
I wouldn't say that it should not have been added since its presence isn't
harming anything. You could say, though, that rarely anyone would realize
something was missing if Clojure didn't have the STM.
On Wednesday, December 12, 2012 9:50:31 AM UTC+1, john wrote:
>
> So is the bottom line: STM
So is the bottom line: STM Should have not been added to clojure ( because it
is not pratical)
Many Grettings
John
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from ne
Yes, upon second thought I saw exactly what you mean.
I think you make an important point: when talking about the STM we need to
look at the wider picture. Where a mutable-by-default language needs the
STM, Clojure gets by with just atoms because a single swap! call can do any
number of mutati
Is it possible to write a reducing function that mutates a list in Clojure?
Sure. But I think it is absurdly unlikely that it would happen by accident.
My 1% chance wasn't hedging against that case -- I was hedging against a
bug in reduce itself.
I don't really see even a 1% likelihood of either
I want to +1 what Stuart said. In my research on the subject, almost every
implementation of STM that allows for mutable-by-default data has ended up
as a miserable failure.
Specifically see the results from Microsoft's research:
http://www.infoq.com/news/2010/05/STM-Dropped
Clojure's implementat
Just curious, how did you immediately eliminate the possibility that the
reducing function was mutating the list that is being reduced? No
concurrency involved. In regular Java the 95% leading cause of CME is
precisely that.
Anyway, this applies to immutable structures per se, whether combined
Hi Paul,
Here is a real-world, production software example of the advantage of
values+refs over mutable objects and locks. A Datomic user reported the
following stack trace as a potential bug:
12:45:43.480 [qtp517338136-84] WARN c.v.a.s.p.e.UnknownExceptionHandler -
UnknownExceptionHandler: null
Hi Paul,
If it isn't too late to change your chapter title, I would encourage
emphasizing Clojure's model of references and values in general, and the
option of implementing a variety of different reference semantics that all
conform to the same basic API shape.
That general approach has been gam
I am unsure whether you are writing about STM in general or in Clojure
specifically.
I worked for Gemstone Systems for five years on the object engine as well
as applications of the distributed, multi-user, garbage-collected STM that
is the centerpiece of Gemstone Smalltalk. During that time I
To give the full story, I should add that atoms are very natural to use and
many concurrent use cases are covered by them alone. The combination of
atom and immutable vector/map goes a long way and they are also useful even
with mutable data, such as lazy-initialized singletons, resources that n
On Monday, December 10, 2012 3:17:27 PM UTC+1, Chas Emerick wrote:
>
> On Dec 10, 2012, at 8:37 AM, Marko Topolnik wrote:
>
> It's true that STM is "all or nothing", but it is so over the scope of
>> refs you choose. If there's some side-effecting bit you need to do
>> somewhere, then clearly
On Monday, December 10, 2012 3:15:04 PM UTC+1, Paul Butcher wrote:
>
> On 10 Dec 2012, at 13:37, Marko Topolnik >
> wrote:
>
> But concurrency is *all* about performance and throughput. So where is
> the benefit of using correct, slow concurrent mutation? I guess in a
> write-seldom, read-ofte
On Dec 10, 2012, at 8:37 AM, Marko Topolnik wrote:
> It's true that STM is "all or nothing", but it is so over the scope of refs
> you choose. If there's some side-effecting bit you need to do somewhere,
> then clearly that's not going to fit within a transaction…but that bit will
> often fit
On 10 Dec 2012, at 13:37, Marko Topolnik wrote:
> But concurrency is all about performance and throughput. So where is the
> benefit of using correct, slow concurrent mutation? I guess in a
> write-seldom, read-often scenario.
I'm not at all sure that that's true. There are plenty of occasions
On 10 Dec 2012, at 12:56, Chas Emerick wrote:
> I'd be surprised if Paul doesn't hear from people directly
I wish that that were true, but no, I've not had anyone get in touch off-list.
Many thanks, Marko, for resurrecting the thread - I'm still definitely keen to
hear of first-hand experience
On Monday, December 10, 2012 1:56:08 PM UTC+1, Chas Emerick wrote:
>
> On Dec 10, 2012, at 5:39 AM, Marko Topolnik wrote:
>
> I personally have never used STM in nontrivial ways (AFAIC), but that's
> due more to the demands of the problems I run into more than anything else.
> On the other ha
On Dec 10, 2012, at 5:39 AM, Marko Topolnik wrote:
> The very fact that there has been no reply to this for five days may mean
> something. I can personally attest to STM being very difficult to put to
> real-life use because there is always that one thing you absolutely need for
> your problem
The very fact that there has been no reply to this for five days may mean
something. I can personally attest to STM being very difficult to put to
real-life use because there is always that one thing you absolutely need
for your problem, that is mutable and not transactional. Most of the time
i
All,
I have a request which I hope the members of this group are uniquely positioned
to help with. I have recently started working on a new book for The Pragmatic
Programmers with the working title "Seven Concurrency Models in Seven Weeks"
(it follows on from their existing "Seven Languages" an
39 matches
Mail list logo
