Atomic ets

[Thomas Lindgren]

--- "Vlad Dumitrescu XX (LN/EAB)"
<vlad.xx.dumitrescu@REDACTED> wrote:
> Please correct me if I'm wrong, but when just
> updating a row there
> shouldn't be a big problem since this "lock" is held
> just briefly. It's
> possible that most clients won't notice it (this is
> true for a single
> CPU, where there's just one execution context
> running at a given time
> anyway, right?).

Your operation will still have to wait until all
preceding table requests are done, regardless of
whether they overlap with yours. If these requests
arrive at a rate such that the table owner message
queue doesn't build up, good. Otherwise, very bad :-)

> Where the problem would be more visible is when
> doing many/bulk updates
> to only one part of a table, while others might need
> to read from
> unrelated parts. 

That's one example.

> This brings up a (mad?) vision: if Erlang processes
> had internal threads
> (or in a equivalent view, several processes shared
> state), then one
> could only "lock part of a table" for each one of
> those. 
> 
> Hmmm, what a can of worms... ;-)

Heh heh, yes indeed :-)

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com