Merge branch 'newManual' into charm
authorRamprasad Venkataraman <ramv@illinois.edu>
Tue, 18 Sep 2012 23:00:21 +0000 (18:00 -0500)
committerRamprasad Venkataraman <ramv@illinois.edu>
Tue, 18 Sep 2012 23:00:21 +0000 (18:00 -0500)
Surprising number of conflicts for something like this.
The conflict in bgp/conv-mach was pure whitespace!

Also restored source for matmul2d example which seems non-empty, contrary
to what commit 69e437925524ecb3 claims.

Conflicts:
doc/charm++/order.tex
doc/libraries/liveviz.tex
examples/charm++/topology/matmul2d/matmul2d.C
src/arch/bluegenep/conv-mach.h

1  2 
doc/charm++/order.tex
doc/libraries/liveviz.tex

index 985f1241c91aa92e9971691806bab1df69cb3ddb,94d3032242722c517b2c8d0df73fde79d92bccbb..f955ada6d513b0987959c4418e001c49d1bb3058
@@@ -1,17 -1,11 +1,14 @@@
- \subsection{Delivery Order}
+ \section{Controlling Delivery Order}
  
- By default, \charmpp\ will process the messages you send in roughly
- FIFO\index{message delivery order} order when they arrive at a PE.
- For most programs, this behavior is fine.  However, for optimal
- performance, some programs need more explicit control over the order
- in which messages are processed. \charmpp\ allows you to adjust
- delivery order on a per-message basis.
- % Example general use cases here
+ By default, \charmpp\ processes the messages sent in roughly FIFO\index{message
+   delivery order} order when they arrive at a PE.  For most programs, this
+ behavior is fine. However, for optimal performance, some programs need more
+ explicit control over the order in which messages are processed. \charmpp\
+ allows you to adjust delivery order on a per-message basis.
  
 +An example program demonstrating how to modify delivery order for messages and
 +parameter marshaling can be found in \examplerefdir{prio}.
 +
  \subsubsection{Queueing Strategies}
  \label{queueing strategies}
  
index 5804047840c7b16aa3710bbc66bb3cf016a25594,edec19142dc15d118ebf391a1417c0ed1e149903..3d6293c57c2a2c6ed56e4122f92df12c623c9180
@@@ -198,10 -193,3 +198,11 @@@ The differences in Poll Mode may be app
  The server should call Deposit with the same global size and combiner type on all of the array elements which correspond to the ``this'' parameter.
  
  The latest version of liveVizPoll is not backwards compatable with older versions. The old version had some fundamental problems which would occur if a server generated an image before a client requested it. Thus the new version buffers server generated images until requested by a client. Furthermore the client requests are also buffered if they arrive before the server generates the images. Problems could also occur during migration with the old version.
 +
 +\section{Caveats}
 +If you use the old version of ``liveVizInit" method that only receives 3 parameters, you will find a known bug caused by how ``liveVizDeposit'' internally uses a reduction to build the image.
 +
 +Using that version of the ``liveVizInit" method, its contribute call is handled as if it were the chare calling ``liveVizDeposit'' that actually contributed to the liveViz reduction.
 +If there is any other reduction going on elsewhere in this chare, some liveViz contribute calls might be issued before the corresponding non-liveViz contribute is reached.
 +This would imply that image data would be treated as if were part of the non-liveViz reduction, leading to unexpected behavior potentially anywhere in the non-liveViz code.
++