Changeset 60c3d87e
- Timestamp:
- Jun 19, 2023, 9:36:21 AM (20 months ago)
- Branches:
- master
- Children:
- 6d18ddb
- Parents:
- 7c012e8
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/colby_parsons_MMAth/text/actors.tex
r7c012e8 r60c3d87e 7 7 % C_TODO: add citations throughout chapter 8 8 Actors are an indirect concurrent feature that abstracts threading away from a programmer, and instead provides \gls{actor}s and messages as building blocks for concurrency, where message passing means there is no shared data to protect, making actors amenable in a distributed environment. 9 Actors are another message passing concurrency feature, similar to channels but with more abstraction, and are in the realm of \gls{impl_concurrency}, where programmers write concurrent code without dealing with explicit thread creat eor interaction.9 Actors are another message passing concurrency feature, similar to channels but with more abstraction, and are in the realm of \gls{impl_concurrency}, where programmers write concurrent code without dealing with explicit thread creation or interaction. 10 10 The study of actors can be broken into two concepts, the \gls{actor_model}, which describes the model of computation and the \gls{actor_system}, which refers to the implementation of the model. 11 11 Before discussing \CFA's actor system in detail, it is important to first describe the actor model, and the classic approach to implementing an actor system. … … 267 267 % As part of packaging the envelope, the @?<<?@ routine sets a routine pointer in the envelope to point to the appropriate receive routine for given actor and message types. 268 268 269 \subsection{Actor Send}\label{s:ActorSend} 269 \subsection{Actor Send}\label{s:ActorSend} % C_TODO: rework this paragraph based on discussion with Mike, see ~/cfa-cc/actor_poly.tex for notes (and fangren's resolver changes) 270 270 All message sends are done using the left-shift operator, @<<@, similar to the syntax of \CC's stream output. 271 271 As stated, \CFA does not have named inheritance with RTTI. … … 340 340 Since all messages to a given actor are in the same queue, this guarantees atomicity across behaviours of that actor since it can only execute on one thread at a time. 341 341 After running a behaviour, the executor thread examines the returned allocation status from the @receive@ routine for the actor and internal status in the delivered message, and takes the appropriate action. 342 Once all actors have marked themselves as being finished the executor initiates shutdown by inserting a sentinel value into the message queues. 342 Once all actors have marked themselves as being finished the executor initiates shutdown by inserting a sentinel value into the message queues. % C_TODO: potentially change if I keep shutdown flag change 343 343 Once a executor threads sees a sentinel it stops running. 344 344 After all executors stop running the actor system shutdown is complete. … … 348 348 Because a C program manages message lifetime, messages cannot be copied for each send, otherwise who manages the copies. 349 349 Therefore, it up to the actor program to manage message life-time across receives. 350 However, for a message to appear on multiple message queues, it needs an arbitrary number of link fields.350 However, for a message to appear on multiple message queues, it needs an arbitrary number of associated destination behaviours. 351 351 Hence, there is the concept of an envelop, which is dynamically allocated on each send, that wraps a message with any extra implementation fields needed to persist between send and receive. 352 352 Managing the envelop is straightforward because it is created at the send and deleted after the receive, \ie there is 1:1 relationship for an envelop and a many to one relationship for a message. 353 354 % In actor systems, messages are sent and received by actors.355 % When a actor receives a message it executes its behaviour that is associated with that message type.356 % However the unit of work that stores the message, the receiving actor's address, and other pertinent information needs to persist between send and the receive.357 % Furthermore the unit of work needs to be able to be stored in some fashion, usually in a queue, until it is executed by an actor.358 % All these requirements are fulfilled by a construct called an envelope.359 % The envelope wraps up the unit of work and also stores any information needed by data structures such as link fields.360 361 % One may ask, "Could the link fields and other information be stored in the message?".362 % This is a good question to ask since messages also need to have a lifetime that persists beyond the work it delivers.363 % However, if one were to use messages as envelopes then a message would not be able to be sent to multiple actors at a time.364 % Therefore this approach would just push the allocation into another location, and require the user to dynamically allocate a message for every send, or require careful ordering to allow for message reuse.365 353 366 354 Unfortunately, this frequent allocation of envelopes for each send results in heavy contention on the memory allocator. … … 397 385 The next time 19 messages are enqueued, the array size is doubled to 36! 398 386 To avoid this issue a second check is added. 399 Each copy queue started trackingthe utilization of its array size.387 Each copy queue now tracks the utilization of its array size. 400 388 Reclamation only occurs if less than half of the array is utilized. 401 389 In doing this, the reclamation scheme is able to achieve a lower high-watermark and a lower overall memory utilization compared to the non-reclamation copy queues.
Note: See TracChangeset
for help on using the changeset viewer.