[erlang-questions] Does read-write lock has a better performance than actor model?
Tue Apr 15 16:34:06 CEST 2014
By "resource" I meas the state in processes. Such as the State in
gen_server or gen_fsm.
I think Fred's method is good if performance really matters. Though it is a
2014-04-15 22:28 GMT+08:00 Aidan Hobson Sayers <>:
> I think you need to clarify what kind of resource you're talking about.
> E.g. multiple read operations on a flat file doesn't need locks, but you
> physically cannot read it in concurrently. You have to have some way of
> coordinating, be it by locking or letting the kernel do it.
> The details of the answer change depending on what specifically you're
> trying to do. But in short, there's very likely a way to do what you want.
> On 15 April 2014 14:46, Bin Wang <> wrote:
>> I meas if there is a write, then give it a lock. If all the requests are
>> read operations, then no lock is needed. That means multiple read
>> operations could be doing at the same time while there is no write
>> However, in actor model, the requests are always handled one by one no
>> matter they are reads or writes. So didn't it slow at some situations?
>> (Read are more that write).
>> Bin Wang
>> 2014-04-15 21:37 GMT+08:00 Dmitry Kolesnikov <>:
>>> No, this is not good.
>>> Any on-going “write request” makes changes to the state. The read
>>> request does not know when the state becomes consistent unless there is a
>>> lock on the state. You cannot ensure safe reading while writes is going on.
>>> Therefore, actor model has bigger advantage.
>>> - Dmitry
>>> On 15 Apr 2014, at 16:31, Bin Wang <> wrote:
>>> > In Erlang, we handle concurrency in such a way: a process receives
>>> messages in its mailbox. And handle them one by one, just one in the same
>>> > But in some situation, the request just want to read the resource. So
>>> the read requests should be able to execute at the same time since they
>>> don't change or break anything.
>>> > So dose this meas if we use a write lock in such situation, we will
>>> have a better performance? If so, does Erlang have a proper way to do that?
>>> > Thanks.
>>> > ---
>>> > Bin Wang
>>> > _______________________________________________
>>> > erlang-questions mailing list
>>> > http://erlang.org/mailman/listinfo/erlang-questions
>> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions