[erlang-questions] Does read-write lock has a better performance than actor model?

[Bin Wang]

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
little tricky.


2014-04-15 22:28 GMT+08:00 Aidan Hobson Sayers <aidanhs@REDACTED>:

> 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 <wbin00@REDACTED> 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
>> operations.
>>
>> 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 <dmitry@REDACTED>:
>>
>>> Hello,
>>>
>>> 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 <wbin00@REDACTED> 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
>>> time.
>>> >
>>> > 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
>>> > erlang-questions@REDACTED
>>> > http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140415/b11087eb/attachment.htm>