Actor Model : Can we get the semantics of a shared lock with the actor model?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
The fact that an actor processes one message at a time and encapsulates state, which it does not share, is sufficient to provide synchronization semantics. So mutual exclusion (write-lock) is taken care of. However how do we go about implementing a read-write lock semantics where multiple readers can work in parallel but readers and writers are mutually exclusive? Eg : Concurrent HashMap.
erlang akka actor otp actor-model
asked Nov 16 '18 at 19:15
rahulrahul
56331121
add a comment |
The fact that an actor processes one message at a time and encapsulates state, which it does not share, is sufficient to provide synchronization semantics. So mutual exclusion (write-lock) is taken care of. However how do we go about implementing a read-write lock semantics where multiple readers can work in parallel but readers and writers are mutually exclusive? Eg : Concurrent HashMap.
erlang akka actor otp actor-model
asked Nov 16 '18 at 19:15
rahulrahul
56331121
1
do you think that actors and concurrent hashmap are related topics? They are not.
– Alexei Kaigorodov
Nov 17 '18 at 13:23
for that you will have to write your own lead-election process it could be anything based on your requirement.
– Raman Mishra
Nov 18 '18 at 18:17
in theory, you can, but why would you want to?
– Zachary K
Jan 31 at 13:37
add a comment |
The fact that an actor processes one message at a time and encapsulates state, which it does not share, is sufficient to provide synchronization semantics. So mutual exclusion (write-lock) is taken care of. However how do we go about implementing a read-write lock semantics where multiple readers can work in parallel but readers and writers are mutually exclusive? Eg : Concurrent HashMap.
erlang akka actor otp actor-model
asked Nov 16 '18 at 19:15
rahulrahul
56331121
The fact that an actor processes one message at a time and encapsulates state, which it does not share, is sufficient to provide synchronization semantics. So mutual exclusion (write-lock) is taken care of. However how do we go about implementing a read-write lock semantics where multiple readers can work in parallel but readers and writers are mutually exclusive? Eg : Concurrent HashMap.
erlang akka actor otp actor-model
erlang akka actor otp actor-model
asked Nov 16 '18 at 19:15
rahulrahul
56331121
asked Nov 16 '18 at 19:15
rahulrahul
56331121
asked Nov 16 '18 at 19:15
rahulrahul
56331121
asked Nov 16 '18 at 19:15
rahulrahul
56331121
asked Nov 16 '18 at 19:15
rahulrahul
56331121
56331121
1
do you think that actors and concurrent hashmap are related topics? They are not.
– Alexei Kaigorodov
Nov 17 '18 at 13:23
for that you will have to write your own lead-election process it could be anything based on your requirement.
– Raman Mishra
Nov 18 '18 at 18:17
in theory, you can, but why would you want to?
– Zachary K
Jan 31 at 13:37
add a comment |
1
do you think that actors and concurrent hashmap are related topics? They are not.
– Alexei Kaigorodov
Nov 17 '18 at 13:23
for that you will have to write your own lead-election process it could be anything based on your requirement.
– Raman Mishra
Nov 18 '18 at 18:17
in theory, you can, but why would you want to?
– Zachary K
Jan 31 at 13:37
1
1
do you think that actors and concurrent hashmap are related topics? They are not.
– Alexei Kaigorodov
Nov 17 '18 at 13:23
do you think that actors and concurrent hashmap are related topics? They are not.
– Alexei Kaigorodov
Nov 17 '18 at 13:23
for that you will have to write your own lead-election process it could be anything based on your requirement.
– Raman Mishra
Nov 18 '18 at 18:17
for that you will have to write your own lead-election process it could be anything based on your requirement.
– Raman Mishra
Nov 18 '18 at 18:17
in theory, you can, but why would you want to?
– Zachary K
Jan 31 at 13:37
in theory, you can, but why would you want to?
– Zachary K
Jan 31 at 13:37
add a comment |
4 Answers
4
active
oldest
votes
With message-passing, an actor that "models" the lock can handle write/read access modes, with correct permissions. The idea is that other actors send requests to grab the lock to the lock actor, and wait for a reply. Using Erlang, the state of the lock actor can be something like #{writer := boolean(), readers := integer()} and the control loop something like:
%% A writer holds the lock:
loop(#{writer := true, readers := 0}) ->
receive
unlock_write -> loop(#{writer => false, readers => 0})
end;
%% One or more readers hold the lock:
loop(#{writer := false, readers := N}) when N > 0 ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => N + 1});
unlock_read -> loop(#{writer => false, readers => N - 1})
end;
%% No writer or readers hold the lock:
loop(#{writer := false, readers := 0}) ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => 1});
{lock_write, Who} -> Who ! lock_granted, loop(#{writer => true, readers => 0})
end.
Notice how at each state the only messages that can be processed are the ones 'allowed' by that state (e.g. when the lock is held by a writer only an unlock_write message can be processed and change the state).
answered Nov 21 '18 at 8:50
aronisstavaronisstav
5,43631842
add a comment |
In Erlang, you can do this in a few ways. The most obvious way is to use an ETS Table. All ets writes are atomic (even if they contain several records) What might be even better is to setup a protected ets table where 1 process can write but all processes can read.
answered Jan 31 at 13:38
Zachary KZachary K
1,85111934
add a comment |
mutual context in the actor model solution handle by queue concept and its avoiding lock mechanism for handling back pressure.
if you want shard memory use other stuff like ets .
answered Nov 17 '18 at 6:40
Mo EinMo Ein
375
add a comment |
Use gen_server. The hash map can be preserved in the state. You may have functions to operate over the state, the hashmap.
answered Feb 25 at 3:10
Ming L.Ming L.
5923
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53344071%2factor-model-can-we-get-the-semantics-of-a-shared-lock-with-the-actor-model%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
With message-passing, an actor that "models" the lock can handle write/read access modes, with correct permissions. The idea is that other actors send requests to grab the lock to the lock actor, and wait for a reply. Using Erlang, the state of the lock actor can be something like #{writer := boolean(), readers := integer()} and the control loop something like:
%% A writer holds the lock:
loop(#{writer := true, readers := 0}) ->
receive
unlock_write -> loop(#{writer => false, readers => 0})
end;
%% One or more readers hold the lock:
loop(#{writer := false, readers := N}) when N > 0 ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => N + 1});
unlock_read -> loop(#{writer => false, readers => N - 1})
end;
%% No writer or readers hold the lock:
loop(#{writer := false, readers := 0}) ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => 1});
{lock_write, Who} -> Who ! lock_granted, loop(#{writer => true, readers => 0})
end.
Notice how at each state the only messages that can be processed are the ones 'allowed' by that state (e.g. when the lock is held by a writer only an unlock_write message can be processed and change the state).
answered Nov 21 '18 at 8:50
aronisstavaronisstav
5,43631842
add a comment |
With message-passing, an actor that "models" the lock can handle write/read access modes, with correct permissions. The idea is that other actors send requests to grab the lock to the lock actor, and wait for a reply. Using Erlang, the state of the lock actor can be something like #{writer := boolean(), readers := integer()} and the control loop something like:
%% A writer holds the lock:
loop(#{writer := true, readers := 0}) ->
receive
unlock_write -> loop(#{writer => false, readers => 0})
end;
%% One or more readers hold the lock:
loop(#{writer := false, readers := N}) when N > 0 ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => N + 1});
unlock_read -> loop(#{writer => false, readers => N - 1})
end;
%% No writer or readers hold the lock:
loop(#{writer := false, readers := 0}) ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => 1});
{lock_write, Who} -> Who ! lock_granted, loop(#{writer => true, readers => 0})
end.
Notice how at each state the only messages that can be processed are the ones 'allowed' by that state (e.g. when the lock is held by a writer only an unlock_write message can be processed and change the state).
answered Nov 21 '18 at 8:50
aronisstavaronisstav
5,43631842
add a comment |
With message-passing, an actor that "models" the lock can handle write/read access modes, with correct permissions. The idea is that other actors send requests to grab the lock to the lock actor, and wait for a reply. Using Erlang, the state of the lock actor can be something like #{writer := boolean(), readers := integer()} and the control loop something like:
%% A writer holds the lock:
loop(#{writer := true, readers := 0}) ->
receive
unlock_write -> loop(#{writer => false, readers => 0})
end;
%% One or more readers hold the lock:
loop(#{writer := false, readers := N}) when N > 0 ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => N + 1});
unlock_read -> loop(#{writer => false, readers => N - 1})
end;
%% No writer or readers hold the lock:
loop(#{writer := false, readers := 0}) ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => 1});
{lock_write, Who} -> Who ! lock_granted, loop(#{writer => true, readers => 0})
end.
Notice how at each state the only messages that can be processed are the ones 'allowed' by that state (e.g. when the lock is held by a writer only an unlock_write message can be processed and change the state).
answered Nov 21 '18 at 8:50
aronisstavaronisstav
5,43631842
With message-passing, an actor that "models" the lock can handle write/read access modes, with correct permissions. The idea is that other actors send requests to grab the lock to the lock actor, and wait for a reply. Using Erlang, the state of the lock actor can be something like #{writer := boolean(), readers := integer()} and the control loop something like:
%% A writer holds the lock:
loop(#{writer := true, readers := 0}) ->
receive
unlock_write -> loop(#{writer => false, readers => 0})
end;
%% One or more readers hold the lock:
loop(#{writer := false, readers := N}) when N > 0 ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => N + 1});
unlock_read -> loop(#{writer => false, readers => N - 1})
end;
%% No writer or readers hold the lock:
loop(#{writer := false, readers := 0}) ->
receive
{lock_read, Who} -> Who ! lock_granted, loop(#{writer => false, readers => 1});
{lock_write, Who} -> Who ! lock_granted, loop(#{writer => true, readers => 0})
end.
Notice how at each state the only messages that can be processed are the ones 'allowed' by that state (e.g. when the lock is held by a writer only an unlock_write message can be processed and change the state).
answered Nov 21 '18 at 8:50
aronisstavaronisstav
5,43631842
edited Nov 23 '18 at 12:42
answered Nov 21 '18 at 8:50
aronisstavaronisstav
5,43631842
answered Nov 21 '18 at 8:50
aronisstavaronisstav
5,43631842
answered Nov 21 '18 at 8:50
aronisstavaronisstav
5,43631842
5,43631842
add a comment |
add a comment |
In Erlang, you can do this in a few ways. The most obvious way is to use an ETS Table. All ets writes are atomic (even if they contain several records) What might be even better is to setup a protected ets table where 1 process can write but all processes can read.
answered Jan 31 at 13:38
Zachary KZachary K
1,85111934
add a comment |
In Erlang, you can do this in a few ways. The most obvious way is to use an ETS Table. All ets writes are atomic (even if they contain several records) What might be even better is to setup a protected ets table where 1 process can write but all processes can read.
answered Jan 31 at 13:38
Zachary KZachary K
1,85111934
add a comment |
In Erlang, you can do this in a few ways. The most obvious way is to use an ETS Table. All ets writes are atomic (even if they contain several records) What might be even better is to setup a protected ets table where 1 process can write but all processes can read.
answered Jan 31 at 13:38
Zachary KZachary K
1,85111934
In Erlang, you can do this in a few ways. The most obvious way is to use an ETS Table. All ets writes are atomic (even if they contain several records) What might be even better is to setup a protected ets table where 1 process can write but all processes can read.
answered Jan 31 at 13:38
Zachary KZachary K
1,85111934
answered Jan 31 at 13:38
Zachary KZachary K
1,85111934
answered Jan 31 at 13:38
Zachary KZachary K
1,85111934
answered Jan 31 at 13:38
Zachary KZachary K
1,85111934
1,85111934
add a comment |
add a comment |
mutual context in the actor model solution handle by queue concept and its avoiding lock mechanism for handling back pressure.
if you want shard memory use other stuff like ets .
answered Nov 17 '18 at 6:40
Mo EinMo Ein
375
add a comment |
mutual context in the actor model solution handle by queue concept and its avoiding lock mechanism for handling back pressure.
if you want shard memory use other stuff like ets .
answered Nov 17 '18 at 6:40
Mo EinMo Ein
375
add a comment |
mutual context in the actor model solution handle by queue concept and its avoiding lock mechanism for handling back pressure.
if you want shard memory use other stuff like ets .
answered Nov 17 '18 at 6:40
Mo EinMo Ein
375
mutual context in the actor model solution handle by queue concept and its avoiding lock mechanism for handling back pressure.
if you want shard memory use other stuff like ets .
answered Nov 17 '18 at 6:40
Mo EinMo Ein
375
answered Nov 17 '18 at 6:40
Mo EinMo Ein
375
answered Nov 17 '18 at 6:40
Mo EinMo Ein
375
answered Nov 17 '18 at 6:40
Mo EinMo Ein
375
375
add a comment |
add a comment |
Use gen_server. The hash map can be preserved in the state. You may have functions to operate over the state, the hashmap.
answered Feb 25 at 3:10
Ming L.Ming L.
5923
add a comment |
Use gen_server. The hash map can be preserved in the state. You may have functions to operate over the state, the hashmap.
answered Feb 25 at 3:10
Ming L.Ming L.
5923
add a comment |
Use gen_server. The hash map can be preserved in the state. You may have functions to operate over the state, the hashmap.
answered Feb 25 at 3:10
Ming L.Ming L.
5923
Use gen_server. The hash map can be preserved in the state. You may have functions to operate over the state, the hashmap.
answered Feb 25 at 3:10
Ming L.Ming L.
5923
answered Feb 25 at 3:10
Ming L.Ming L.
5923
answered Feb 25 at 3:10
Ming L.Ming L.
5923
answered Feb 25 at 3:10
Ming L.Ming L.
5923
5923
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53344071%2factor-model-can-we-get-the-semantics-of-a-shared-lock-with-the-actor-model%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
do you think that actors and concurrent hashmap are related topics? They are not.
– Alexei Kaigorodov
Nov 17 '18 at 13:23
for that you will have to write your own lead-election process it could be anything based on your requirement.
– Raman Mishra
Nov 18 '18 at 18:17
in theory, you can, but why would you want to?
– Zachary K
Jan 31 at 13:37