Context Navigation

-                      rd3c3261
+                      r000d68f
 Therefore, it is up to the actor program to manage message life-time across receives.
 However, for a message to appear on multiple message queues, it needs an arbitrary number of associated destination behaviours.
 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.
 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.
+Hence, there is the concept of an envelope, which is dynamically allocated on each send, that wraps a message with any extra implementation fields needed to persist between send and receive.
+Managing the envelope is straightforward because it is created at the send and deleted after the receive, \ie there is 1:1 relationship for an envelope and a many to one relationship for a message.
 % In actor systems, messages are sent and received by actors.
 …
 Users could be expected to write the @?|?@ routines, but this approach is error prone and creates maintenance issues.
 Until the \CFA type-system matures, I created a workaround using a template-like approach, where the compiler generates a matching @?|?@ routine for each @receive@ routine it finds with the correct actor/message type-signature.
 This workaround is outside of the type system, but performing a type-system like action.
+As a stopgap until the \CFA type-system matures, a workaround was created using a template-like approach, where the compiler generates a matching @?|?@ routine for each @receive@ routine it finds with the correct actor/message type-signature.
+This workaround is outside of the type system, but performs a type-system like action.
 The workaround requires no annotation or additional code to be written by users;
 thus, it resolves the maintenance and error problems.
 …
 The routine sets @rec_fn@ to the matching @receive@ routine using the left-hand type to perform the selection.
 Then the routine packages the actor and message, along with the receive routine into an envelope.
 Finally, the envelop is added to the executor queue designated by the actor using the executor routine @send@.
+Finally, the envelope is added to the executor queue designated by the actor using the executor routine @send@.
 \begin{figure}
 …
 \subsection{Actor Termination}\label{s:ActorTerm}
 During a message send, the receiving actor and message being sent are stored via pointers in the envelope.
 These pointers are the base actor and message types, so type information of the derived actor and message is lost and must be recovered later when the typed receive routine is called.
+These pointers have the base actor and message types, so type information of the derived actor and message is lost and must be recovered later when the typed receive routine is called.
 After the receive routine is done, the executor must clean up the actor and message according to their allocation status.
 If the allocation status is @Delete@ or @Destroy@, the appropriate destructor must be called by the executor.
 …
 the derived type of the actor or message is not available to the executor, but it needs to call the derived destructor.
 This requires downcasting from the base type to the derived type, which requires a virtual system.
 To accomplish the dowcast, I implemented a rudimentary destructor-only virtual system in \CFA.
+To accomplish the downcast, a rudimentary destructor-only virtual system was implemented in \CFA as part of this work.
 This virtual system is used via Plan-9 inheritance of the @virtual_dtor@ type, shown in Figure~\ref{f:VirtDtor}.
 The @virtual_dtor@ type maintains a pointer to the start of the object, and a pointer to the correct destructor.
 …
 Since the copy queue is an array, envelopes are allocated first on the stack and then copied into the copy queue to persist until they are no longer needed.
 For many workload, the copy queues grow in size to facilitate the average number of messages in flight and there is no further dynamic allocations.
+For many workloads, the copy queues grow in size to facilitate the average number of messages in flight and there are no further dynamic allocations.
 The downside of this approach is that more storage is allocated than needed, \ie each copy queue is only partially full.
 Comparatively, the individual envelope allocations of a list-based queue mean that the actor system always uses the minimum amount of heap space and cleans up eagerly.
 …
 However, any form of locking here creates contention between thief and victim.
 The alternative to locking is allowing the race and resolving it lazily (lock-free approach).
+The alternative to locking is allowing the race and resolving it lazily.
 % As mentioned, there is a race between a victim gulping and a thief stealing because gulping partitions a mailbox queue making it ineligible for stealing.
 % Furthermore, after a thief steals, there is moment when victim gulps but the queue no longer
 …
 Because $Z$ is contiguous in memory, there can be small cache write-contention at the row boundaries.
 Figures~\ref{f:MatrixAMD} and \ref{f:MatrixIntel} show the matrix multiple results.
+Figures~\ref{f:MatrixAMD} and \ref{f:MatrixIntel} show the matrix-multiply results.
 There are two groupings with Akka and ProtoActor being slightly slower than \uC, \CFA, and CAF.
 On the Intel, there is an unknown divergence between \uC and \CFA/CAF at 24 cores.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 000d68f for doc/theses/colby_parsons_MMAth/text/actors.tex

Legend:

doc/theses/colby_parsons_MMAth/text/actors.tex

Download in other formats: