This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "aesop Repository".
The branch, master has been updated
via b24e4a2943cff168708d4110b41ca45f6c58bc83 (commit)
via fb9d6a547936c1f0be3cab1213f0f39374e9098e (commit)
via 4bdc5b8a5cf97a4a2d3a3aac58165817f9c88cee (commit)
from 740dd98e4720d8c6cf15b5003d5236d7ed858919 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit b24e4a2943cff168708d4110b41ca45f6c58bc83
Author: Dries Kimpe <dkimpe(a)mcs.anl.gov>
Date: Tue Feb 14 14:05:03 2012 -0600
Update cancel document based on meeting discussion
- Make the cancel flag sticky to:
- avoid race between aesop cancelling and the underlying operation
cancel
- Allow the resource to return success if the cancel request was
received by the resource but the operation completed at the same
time. By having a sticky cancel flag, we no longer use the return
code of the resource as the notification of a request to cancel,
since the next blocking call will instead deliver the notification
(as it will do immediate completion indicating cancel)
commit fb9d6a547936c1f0be3cab1213f0f39374e9098e
Author: Dries Kimpe <dkimpe(a)mcs.anl.gov>
Date: Fri Feb 10 19:53:48 2012 -0600
No need for aecc-utils to be executable
commit 4bdc5b8a5cf97a4a2d3a3aac58165817f9c88cee
Author: Dries Kimpe <dkimpe(a)mcs.anl.gov>
Date: Fri Feb 10 18:29:05 2012 -0600
Aesop user guide and performance guide.
-----------------------------------------------------------------------
Summary of changes:
configure.ac | 3 +-
doc/aesop-pbranch-cancel.txt | 26 +++++++++------
doc/aesop-user-guide.txt | 72 ++++++++++++++++++++++++++++++++++++++++++
doc/aesop.txt | 33 -------------------
doc/module.mk.in | 4 ++
5 files changed, 94 insertions(+), 44 deletions(-)
create mode 100644 doc/aesop-performance.txt
create mode 100644 doc/aesop-user-guide.txt
delete mode 100644 doc/aesop.txt
create mode 100644 doc/module.mk.in
Diff of changes:
diff --git a/configure.ac b/configure.ac
index 6912ff4..bc69217 100644
--- a/configure.ac
+++ b/configure.ac
@@ -287,7 +287,7 @@ AC_SUBST(BLOCKSOPT)
AC_SUBST(LIBCFLAGS)
AC_SUBST(THREAD_LIB)
-AC_CONFIG_FILES([bin/aecc-utils], [chmod +x bin/aecc-utils])
+AC_CONFIG_FILES([bin/aecc-utils], [])
AC_CONFIG_FILES([bin/aecc], [chmod +x bin/aecc])
AC_OUTPUT([Makefile
@@ -305,5 +305,6 @@ parser/module.mk
parser/tests/blocking/module.mk
src/socket/module.mk
src/socket/test/module.mk
+doc/module.mk
])
diff --git a/doc/aesop-pbranch-cancel.txt b/doc/aesop-pbranch-cancel.txt
index 712f5f2..61b9ce1 100644
--- a/doc/aesop-pbranch-cancel.txt
+++ b/doc/aesop-pbranch-cancel.txt
@@ -62,11 +62,17 @@ Problems with the current implementation:
=== Semantics of the aesop-level cancel:
* totally asynchronous (no longer blocks until pbranches exit)
* cancel signal to pbranch is guaranteed to be delivered exactly once
-** will affect current resource operation (if present) or the next one to
- be posted
-** cancel status is cleared for a pbranch once it has impacted one blocking
- resource call (so pbranch can issue blocking cleanup functions safely if
- it needs to)
+* Cancel sets a flag in the execution context of the pbranch
+** will affect current resource operation (if present), calling the cancel
+ function of the resource.
+** If no resource call is active, it will simply set the flag in the execution
+context.
+** The cancel flag remains in the pbranch execution context. Currently we do
+not plan to provide a way to clear the flag.
+** The resources are responsible for checking the flag in the post functions,
+and return immediately with an appropriate error code if they detect the
+cancel flag is set.
+
* cancel will return true if it succeeded in delivering the cancel request,
false if it detects that another pbranch *at the same scope or higher*
already issued a cancel
@@ -83,7 +89,7 @@ Problems with the current implementation:
question (and the operation is guaranteed to return ECANCEL or
whatever is appropriate for the resource)
* returns false if it failed to cancel the operation in question
-* cancel function can no longer issue op callback directly (this complicates
+* cancel function is no longer allowed to call the op callback directly (this complicates
some possible deadlock scenarios)
=== Aesop internal implementation details:
@@ -101,13 +107,13 @@ Problems with the current implementation:
** proceed recursively, setting flag in child pbranches in the same manner
=== Semantics of the resource-level post functions:
-* will have hook to check (and clear) parent ctrl structure cancel flag
+* will have hook to check parent ctrl structure cancel flag
* if detect that pbranch has cancelled, the post should immediately fail
with appropriate return code for resource
=== Misc:
-* provide helper functions is_cancelled() and clear_cancelled() so a pbranch
- can check and clear it's cancelled status manually if it wants to
+* provide helper functions is_cancelled() so a pbranch
+ can check it's cancelled status manually if it wants to
* One possible implementation idea is to treat child pwait blocks as
resources, so that they generate op ids and have a cancel function just
like a resource call. Might make the aesop code a little cleaner in
@@ -178,7 +184,7 @@ Example resource cancel semantics:
triton_ret_t resource_post(void)
{
/* don't start op if we have a pending, undelivered cancel signal */
- if(test_and_clear_cancelled_state())
+ if(test_cancelled_state())
return(ECANCELLED);
/* do whatever .... */
diff --git a/doc/aesop-performance.txt b/doc/aesop-performance.txt
new file mode 100644
index 0000000..e69de29
diff --git a/doc/aesop-user-guide.txt b/doc/aesop-user-guide.txt
new file mode 100644
index 0000000..550ff16
--- /dev/null
+++ b/doc/aesop-user-guide.txt
@@ -0,0 +1,72 @@
+
+Aesop
+=====
+
+== Source files
+
+Aesop source and header files are named *.ae and *.hae, respectively. They
+are used exactly like c source and header files, except that they support
+additional constructs, such as the __blocking qualifier for functions and
+the pwait and pbranch constructs.
+
+In addition, Aesop remote code (ie, RPC functions) can be found in .aer and
+.haer functions. These source files support an additional __remote
+qualifier for functions to be invoked via RPC.
+
+== Compilers
+
+The configure process produces two compilers in the maint/ directory. aecc
+is a compiler for .ae files, and aercc is a compiler for .aer files. Both
+are shell scripts that combine preprocessing, source translation, and
+compilation into one step.
+
+[source,c]
+----
+sdafa
+sdfa
+sdfasdf
+----
+
+== Resources
+
+Resources are the lowest level aesop components that present Aesop
+compatible intefaces for managing concurrency. The current list of
+resources includes:
+
+* file resource
+** code/src/versioned-osd/prototype/file-resource
+** provides a mapping of open, close, read, write etc. functions. It uses
+ a thread pool by default to implement nonblocking semantics.
+
+* Berkeley DB resource
+** code/src/versioned-osd/prototype/bdb-resource
+** provides a mapping of common Berkeley DB functions. It uses a thread
+ pool by default to implement nonblocking semantics.
+
+* socket resource
+** code/src/common/resources/aesocket/
+** waits for a file descriptor to be ready for read or write operations.
+ It does not implement actual read or write calls; it is assumed that the
+ caller will use this resource in conjunction with nonblocking reads and
+ writes. It uses libev, which in turn uses epoll() on Linux.
+
+* timer resource
+** code/src/common/resources/timer/
+** implements timers with millisecond resolution. The underlying
+ implementation uses libev.
+
+* scheduling resource
+** code/src/common/resource/scheduling/
+** Implements various synchronization primitives, for example Aesop
+ equivalents for condition variables.
+
+* branch threader resource
+** code/src/common/resource/branch-threader/
+** Proof of concept that allows the developer to manually allocate a thread
+ for particular aesop code blocks.
+
+== Test programs
+
+A variety of tests and/or examples for Aesop functionality can be found in
+the code/src/aesop/parser/tests/blocking directory. These tests use a
+dummy resource to demonstrate various language features.
diff --git a/doc/aesop.txt b/doc/aesop.txt
deleted file mode 100644
index e1e3d7d..0000000
--- a/doc/aesop.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Aesop
-=====
-
-== Source files
-
-Aesop source and header files are named *.ae and *.hae, respectively. They
-are used exactly like c source and header files, except that they support
-additional constructs, such as the __blocking qualifier for functions and
-the pwait and pbranch constructs.
-
-In addition, Aesop remote code (ie, RPC functions) can be found in .aer and
-.haer functions. These source files support an additional __remote
-qualifier for functions to be invoked via RPC.
-
-== Compilers
-
-The configure process produces two compilers in the maint/ directory. aecc
-is a compiler for .ae files, and aercc is a compiler for .aer files. Both
-are shell scripts that combine preprocessing, source translation, and
-compilation into one step.
-
-== Resources
-
-Resources are the lowest level aesop components that present Aesop
-compatible intefaces for managing concurrency. An example is the timer
-resource, found in aesop/resource/timer. It implements timers with
-millisecond resolution. The underlying implementation uses libev.
-
-== Test programs
-
-A variety of tests and/or examples for Aesop functionality can be found in
-the aesop/parser/tests/blocking directory. These tests use a
-dummy resource to demonstrate various language features.
diff --git a/doc/module.mk.in b/doc/module.mk.in
new file mode 100644
index 0000000..979af15
--- /dev/null
+++ b/doc/module.mk.in
@@ -0,0 +1,4 @@
+ASCIIDOCSRC += doc/aesop-user-guide.txt \
+ doc/aesop-performance.txt \
+ doc/aesop-pbranch-cancel.txt
+
hooks/post-receive
--
aesop Repository
