Bruda.CA - part:papers

a_case_study_in_real-time_parallel_computation_-_correcting_algorithms

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:45:24+00:00

Thu 23 Apr 2026 1:11 am -0400		current
Line 1:		Line 1:
		+	{{:part:papers:c-algorithms.pdf\|This document}} is an earlier version of the paper by Stefan D. Bruda and Selim G. Akl published in the Journal of Parallel and Distributed Computing 61 (2001).

a_distributed_architecture_for_remote_service_discovery_in_pervasive_computing

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:35:22+00:00

Tue 30 Oct 2012 10:36 pm -0400		current
Line 1:		Line 1:
	by Farzad Salehi, Stefan D. Bruda, Yasir Malik, and Bessam Abdulrazak.		by Farzad Salehi, Stefan D. Bruda, Yasir Malik, and Bessam Abdulrazak.

-	A [[http://cs.ubishops.ca/_media/papers/bucstr-2012-001.pdf\|unified version]] that includes most of the material from [[http://dx.doi.org/10.1016/j.procs.2012.06.133\|A Peer-to-Peer Architecture for Remote Service Discovery]] (ANT 2012) and __A Distributed Architecture for Remote Service Discovery in Pervasive Computing__ (ICSOFT 2012) is available.	+	A [[http://www.ubishops.ca/wp-content/uploads/bucstr-2012-001.pdf\|unified version]] that includes most of the material from [[http://dx.doi.org/10.1016/j.procs.2012.06.133\|A Peer-to-Peer Architecture for Remote Service Discovery]] (ANT 2012), __A Distributed Architecture for Remote Service Discovery in Pervasive Computing__ (ICSOFT 2012), and __Peer-to-Peer Remote Service Discovery in Pervasive Computing__ (Springer CCIS vol. 411) is available.

a_testing_theory_for_real-time_systems

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:36:37+00:00

Wed 9 May 2012 4:03 pm -0400		current
Line 1:		Line 1:
	by Chun Dai and Stefan D Bruda, Includes the material from [[http://www.actapress.com/Abstract.aspx?paperId=34334\|A Testing Framework for Real-Time Specifications]] (SEA 2008), __Timed Test Generation Based on Timed Temporal Logic__ (ICAI 2010) and __A Testing Theory for Real-Time Systems__ (International Journal of Computers).		by Chun Dai and Stefan D Bruda, Includes the material from [[http://www.actapress.com/Abstract.aspx?paperId=34334\|A Testing Framework for Real-Time Specifications]] (SEA 2008), __Timed Test Generation Based on Timed Temporal Logic__ (ICAI 2010) and __A Testing Theory for Real-Time Systems__ (International Journal of Computers).

-	An [[http://cs.ubishops.ca/techreps/bucstr-2009-003.pdf\|preliminary version]] is available.	+	An [[http://www.ubishops.ca/wp-content/uploads/bucstr-2009-003.pdf\|preliminary version]] is available.

collapsing_the_hierarchy_of_parallel_computational_models

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:38:09+00:00

Mon 14 May 2012 4:56 pm -0400		current
Line 1:		Line 1:
-	Collapsing the Hierarchy of Parallel Computational Models
-
	By Stefan D. Bruda and Yuanqiao Zhang. Includes material from __The Shared Memory Hierarchy: The PRAM is as powerful as the BSR__ (ISPDC 2008), __Why Shared Memory Matters to VLSI Design: The BSR Is as Powerful as Reconfiguration__ (IPDPS 2008), and [[http://dx.doi.org/10.1142/S0129054110007350\|Collapsing the Hierarchy of Parallel Computational Models]] (IJFCS).		By Stefan D. Bruda and Yuanqiao Zhang. Includes material from __The Shared Memory Hierarchy: The PRAM is as powerful as the BSR__ (ISPDC 2008), __Why Shared Memory Matters to VLSI Design: The BSR Is as Powerful as Reconfiguration__ (IPDPS 2008), and [[http://dx.doi.org/10.1142/S0129054110007350\|Collapsing the Hierarchy of Parallel Computational Models]] (IJFCS).

-	An [[http://cs.ubishops.ca/_media/papers/bucstr-2008-005.pdf\|on-line version]] is available. An extended version has been published under the title [[http://www.amazon.com/Reconfiguration-Shared-Memory-Collapsing-Reconfigurable/dp/383832918X\|Reconfiguration is Shared Memory: Collapsing the Hierarchy of Parallel Models with Reconfigurable Buses and Shared Memory]] (LAP, January 2010).	+	An [[http://www.ubishops.ca/wp-content/uploads/bucstr-2008-005.pdf\|on-line version]] is available. An extended version has been published under the title [[http://www.amazon.com/Reconfiguration-Shared-Memory-Collapsing-Reconfigurable/dp/383832918X\|Reconfiguration is Shared Memory: Collapsing the Hierarchy of Parallel Models with Reconfigurable Buses and Shared Memory]] (LAP, January 2010).

communicating_visibly_pushdown_processes

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:38:59+00:00

Thu 10 May 2012 3:56 pm -0400		current
Line 1:		Line 1:
-	by Stefan D. Bruda and Md. Tawhid Bin Waez, in Proceedings of the 17th International Conference on Control Systems and Computer Science, 26-29 May 2009, Bucharest, Romania. A [[http://cs.ubishops.ca/techreps/bucstr-2008-002.pdf\|preliminary version]] is available.	+	by Stefan D. Bruda and Md. Tawhid Bin Waez, in Proceedings of the 17th
		+	International Conference on Control Systems and Computer Science, 26-29 May
		+	2009, Bucharest, Romania. A
		+	[[http://www.ubishops.ca/wp-content/uploads/bucstr-2008-002.pdf\|preliminary version]] is available.

model_checking_is_refinement_-_from_computation_tree_logic_to_failure_trace_testing

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:40:43+00:00

Thu 10 May 2012 3:53 pm -0400		current
Line 1:		Line 1:
-	by Stefan D. Bruda and Zhyiu Zhang. Includes the material from __Refinement Is Model Checking: From Failure Trace Tests to Computation Tree Logic__ (SEA 2009) and from __Model Checking Is Refinement: From Computation Tree Logic to Failure Trace Testing__ (ICSOFT 2010). An [[http://cs.ubishops.ca/techreps/bucstr-2009-002.pdf\|on-line version]] is available.	+	by Stefan D. Bruda and Zhyiu Zhang. Includes the material from __Refinement Is
		+	Model Checking: From Failure Trace Tests to Computation Tree Logic__ (SEA
		+	2009) and from __Model Checking Is Refinement: From Computation Tree Logic to
		+	Failure Trace Testing__ (ICSOFT 2010). An
		+	[[http://www.ubishops.ca/wp-content/uploads/bucstr-2009-002.pdf\|on-line version]] is available.

on_limits_on_the_computational_power_of_data-accumulating_algorithms

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:47:35+00:00

Wed 9 May 2012 7:50 pm -0400		current
Line 1:		Line 1:
-	A {{:papers:data-acum.pdf\|slightly earlier version}} than the one published in Information Processing Letters (86 (2003), by Stefan D. Bruda and Selim G. Akl) is available.	+	A {{:part:papers:data-acum.pdf\|slightly earlier version}} than the one published in Information Processing Letters (86 (2003), by Stefan D. Bruda and Selim G. Akl) is available. Also includes the material from __On the data-accumulating paradigm__, (Fourth International Conference on Computer Science and Informatics, Research Triangle Park, NC, October 1998).

on_the_computational_complexity_of_context-free_parallel_communicating_grammar_systems

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:46:44+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	By Stefan D. Bruda, {{:part:papers:cf-pcgs.pdf\|this paper}} appeared in Springer Lecture Notes in Computer Science 1218.

on_the_necessity_of_formal_models_for_real-time_parallel_computations

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:53:09+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	By Stefan D. Bruda and Selim G. Akl, in Parallel Processing Letters, 11 (2001). A {{:part:papers:rttm.pdf\|preliminary version}} is available.

parallel_real-time_complexity_theory

Anonymous (anonymous@undisclosed.example.com) — 2020-08-13T15:20:20+00:00

Sun 13 May 2012 4:48 pm -0400		current
Line 1:		Line 1:
-	by Stefan D. Bruda, PhD thesis, Department of Computing and Information Science, Queen's University at Kingston, April 2002. {{:part:papers:rt-cmplx.pdf\|Complete manuscript (930 K characters)}}.	+	by Stefan D. Bruda, PhD thesis, Department of Computing and Information Science, Queen's University at Kingston, April 2002. {{:part:papers:rt-cmplx.pdf\|Complete manuscript}}.

-
-	<blockquote>
	Abstract: We present a new complexity theoretic approach to real-time computations. We define timed omega-languages as a new formal model for such computations, that we believe to allow a unified treatment of all variants of real-time computations that are meaningful in practice. To our knowledge, such a practically meaningful formal definition does not exist at this time.		Abstract: We present a new complexity theoretic approach to real-time computations. We define timed omega-languages as a new formal model for such computations, that we believe to allow a unified treatment of all variants of real-time computations that are meaningful in practice. To our knowledge, such a practically meaningful formal definition does not exist at this time.

Line 12:		Line 10:

	We also address the problem of real-time approximation algorithms. We identify problems that do not admit good approximation solutions in real time. We also show that bin packing admits a good real-time approximation algorithm.		We also address the problem of real-time approximation algorithms. We identify problems that do not admit good approximation solutions in real time. We also show that bin packing admits a good real-time approximation algorithm.
-	</blockquote>

parallel_real-time_cryptography_-_beyond_speedup_ii

Anonymous (anonymous@undisclosed.example.com) — 2012-05-10T20:04:07+00:00

Thu 23 Apr 2026 1:11 am -0400		current
Line 1:		Line 1:
		+	This [[http://research.cs.queensu.ca/TechReports/Reports/1999-423.pdf\|Queen's technical report]] is a preliminary version of the paper in Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications, Las Vegas, NV, 2000.

parallel_real-time_numerical_computation_-_beyond_speedup_iii

Anonymous (anonymous@undisclosed.example.com) — 2012-05-10T19:45:18+00:00

Thu 23 Apr 2026 1:11 am -0400		current
Line 1:		Line 1:
		+	This [[http://research.cs.queensu.ca/TechReports/Reports/1999-424.pdf\|Queen's technical report]] is a preliminary version of the paper in the International Journal of Computers and their Applications, 7 (2000).

parallel_real-time_optimization_-_beyond_speedup

Anonymous (anonymous@undisclosed.example.com) — 2012-05-10T19:47:10+00:00

Thu 23 Apr 2026 1:11 am -0400		current
Line 1:		Line 1:
		+	This [[http://research.cs.queensu.ca/TechReports/Reports/1999-421.pdf\|Queen's technical report]] is a preliminary version of the paper in Parallel Processing Letters, 9 (1999).

parse_trees_and_unique_queries_in_context-free_parallel_communicating_grammar_systems

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:41:50+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	By Stefan D. Bruda and Mary Sarah Ruth Wilkin. Includes material from __Not
	+	Seeing the Parse Trees from the Parse Forest of a Context-Free Parallel
	+	Communicating Grammar System__ (ISPDC 2013) and __Parse Trees for Context-Free
	+	Parallel Communicating Grammar Systems__ (ICAI 2012). An
	+	[[http://www.ubishops.ca/wp-content/uploads/bucstr-2013-001.pdf\|on-line version]] is available.

preorder_relations

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:44:58+00:00

Sun 13 May 2012 4:44 pm -0400		current
Line 1:		Line 1:
	A {{:part:papers:motres-bruda.pdf\|slightly older version}} of the book chapter (by Stefan D. Bruda, in Model-Based Testing of Reactive Systems: Advanced Lectures, Springer Lecture Notes in Computer Science 3472, 2005) is available; note in particular that page numbers do not match. Includes references and index.		A {{:part:papers:motres-bruda.pdf\|slightly older version}} of the book chapter (by Stefan D. Bruda, in Model-Based Testing of Reactive Systems: Advanced Lectures, Springer Lecture Notes in Computer Science 3472, 2005) is available; note in particular that page numbers do not match. Includes references and index.
		+

pursuit_and_evasion_on_a_ring_-_an_infinite_hierarchy_for_parallel_real-time_systems

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:52:15+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	By Stefan D. Bruda and Selim G. Akl. {{:part:papers:pursuit.pdf\|This version}} includes almost all the material from __Parallel Real-Time Complexity: A Strong Infinite Hierarchy__ (SIROCCO 2001) and __Pursuit and Evasion on a Ring: An Infinite Hierarchy for Parallel Real-Time Systems__ (Theory of Computing Systems).

real-time_computation_-_a_formal_definition_and_its_applications

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:46:01+00:00

Thu 23 Apr 2026 1:11 am -0400		current
Line 1:		Line 1:
		+	By Stefan D. Bruda and Selim G. Akl. The {{:part:papers:timed-langs.pdf\|most complete variant}} is available and includes almost all the material from __Towards a meaningful formal definition of real-time computations__, (ISCA 15th International Conference on Computers and Their Applications, 2000), __Real-Time Computation: A Formal Definition and Its Applications__ (IPDPS 2001), and the IJCA paper (an aggregate of the first two).

rtsync_-_overview

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:15:29+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	The principle behind RTSync is to provide a time-constrained, distributed programming language in a familiar setting. The programmer does not need to know about networking, only how to program using the C++ language.

	+	The code that is included in the tarball contains two main components: the compiler and the run- time environment. The compiler is responsible for converting the RTSync code into C++ code and performing a simple analysis of the timing constraints. The run-time environment is responsible for handling the networking components of the system and enforcing the time constraints.
	+
	+	====== Compiler Overview ======
	+
	+	The compiler uses a large tree to analyze the code. The syntax of the language is specified in the two files: parser.yacc and scanner.lex. The programs lex and yacc are required to compile the compiler, since these two programs are what generate the large tree. After the tree is constructed, Several "visitors" are created and traverse through the tree. Each segment of the code has a certain label, for example all the code in a synchronizer will be contained in a synchronizer node. The children of this node are the various parts of the synchronizer, such as the variable declarations, the initialization block, the constraint block, etc. Each of those blocks may then have some children as well.
	+
	+	There are three types of visitor: the code visitor, the scope visitor and the global synchronizer visitor. The code visitor traverses the tree and outputs the C++ code, the scope visitor does type- checking and scope-checking on identifiers, and the global synchronizer visitor is a special visitor that handles global synchronizers. When the compiler is run and the tree has been generated, the code visitor then the scope visitor scans over the code and begins to convert it to C++ code. If a global synchronizer is encountered, a global synchronizer visitor is created to analyze it.
	+
	+	After the code has all been generated, a "sanity check" is done. What this does is checks the timing constraints of the synchronizers to see if there are any impossible situations (like if a minimum constraint is less than a maximum constraint).
	+
	+	If all goes well while compiling the code, an output file is created that is compilable by a C++ compiler. Note that the boost and POSIX libraries are required to compile this file.
	+
	+	====== Run-Time Environment (RTE) Overview ======
	+
	+	The RTSync run-time system is designed to be a message-based, distributed system. Each computer that is running the program has an object created called the "postmaster". The postmaster handles connecting to the other computers, sending messages and handling communications between actors and synchronizers. When a postmaster is created, it can either run a method or it can just start and wait for messages from other postmasters.
	+
	+	The handling of timing constraints and trigger execution is done by the synchronizer object. All synchronizers inherit from the synchronizer class that provides the necessary method prototypes for the synchronizers generated by the RTSync compiler. These include the proper methods for constraint checking, action notification, and trigger polling.
	+	Constraint checking is simple, when a method is called, a notification is sent to the synchronizer that contains information about when the method was sent and received. If this notification violates a timing constraint, then an exception is thrown by calling the generated exception handler.
	+	Action notification is done by using an action listener pattern, where the synchronizer must define a method called notify_action() that takes as parameters information about a method call. When this method is called, then the synchronizer runs through the action statements in the trigger block to see if this particular method call should trigger an action.
	+	Finally the trigger polling is where the synchronizer checks all of the enable/disable statements to see if any methods should be enabled or disabled.
	+
	+	The actor objects simply have their methods redefined using C++ code, and a few functions that handle the receiving of messages from the postmaster. When the message is received, the proper method is run and a message is then sent back to the postmaster with the appropriate information added (such as the time the message was actually received).

rtsync_-_the_compiler

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:18:29+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	The compiler works by constructing a large tree from the source code. The tree is created based on the grammar of the language, specified in the parser.yacc file and the scanner.lex file.

	+	The scanner.lex file contains information on which keywords belong to the language and what constitutes an integer, string or float literal, or a valid variable name. The comment syntax for RTSync is also described in this file. This information has syntax for the LEX lexical analyzer generator ([[http://dinosaur.compilertools.net/#lex\|website]]). This program takes the code in scanner.lex (or whatever other file is specified) and generates code for a lexical analyzer. The lexical analyzer code is currently outputted to a file called lex.yy.c. This code is used to turn the code into a series of tokens that are then read by the parser.
	+
	+	The parser is described in the parser.yacc file. This file is read by the YACC program ([[http://dinosaur.compilertools.net/#yacc\|website]]) which generates a tree based on the tokens sent from the lexical analyzer. Each node in this tree contains a certain block of the code provided. The children of each node then contain a portion of this certain block. An example of this is an actor block contains all the code for an actor and the children of the actor node are the various aspects of the actor, such as the variable declarations, init block and method declarations. The correct syntax for the actor node is defined in the following syntax:
	+
	+	actor_block : ACTOR ID BRACE_OPEN declaration_list BRACE_CLOSE
	+	{ $$ = new actor_node(lineno, $2, $4); }
	+	;
	+
	+	All types of blocks are declared in such a way. Anything that is in all capital letters is defined in the scanner.lex file. This actor_block node requires a syntax that first has the "actor" keyword, followed by a valid identifier, then an opening curly brace ( { ). The declaration_list block is then defined elsewhere in parser.yacc. This block includes the variable declarations, etc. Finally this block is followed by a closing curly brace ( } ). In the C++ code generated by YACC, the actor_block is represented by an actor_node object. The constructor for this object will have three parameters: the line number where the actor is first declared, the identifier and the object returned by the declaration_list block. The $$ is the return value of the actor_block. The $2 and $4 represent the second item and fourth item of the syntax list, respectively (second being the identifier and fourth being the declaration_list). The semicolon terminates the actor_block definition. Note that in the YACC grammar, whitespace is mostly ignored (except, of course, the spaces in between different words).
	+
	+	There are several blocks that include an OR operator ( \| ) in their definitions. An example of this is the module block. A module block is either an actor, a synchronizer, a global synchronizer or something else. The definition for this block looks like this:
	+
	+	module : actor_block
	+	{ $$ = $1; }
	+	\| sync_block
	+	{ $$ = $1; }
	+	\| global_sync
	+	{ $$ = $1; }
	+	\| PASS
	+	{ $$ = new pass_node(lineno, $1); }
	+	;
	+
	+	What this does is first checks the code in the module block to see if it is an actor, if not it checks if it is a synchronizer, then a global synchronizer. If it is none of these, the PASS keyword matches anything else that may be put here and then creates a pass_node object. Semantically, the pass_node object contains anything that is not RTSync code and will treat the code as standard C++ code. In cases where there are several different OR statements, but none of them are matched by the code in the block, the compiler outputs a syntax error.
	+
	+	Once the lexical analyzer and parser are run, the code is now structured as a tree. The tree is then passed to the various visitors which scan over the tree. There are two visitors which scan the entire tree: the code visitor and the scope visitor. The code visitor is the first to run, it traverses the tree and converts the RTSync code into C++ code, outputting all the code to handle the initalization of the postmaster, connecting to the distributed system, etc. The second to run is the scope visitor, which checks to see if there are scope violations or not in the code, or type violations when assigning different values, etc.
	+
	+	The code visitor has a visit() method for each type of node generated by the parser. These methods handle the semantics of each node. Each node has an accept() method that handles its processing. When running the visit() method for each node, the child nodes can be then processed by calling the accept() method of the child. Then for the various list type nodes (like variable declaration lists which have an arbitrary number of nodes) are treated like a linked list, where each of them have a head and a tail. The head is another list, and the tail is an element of the list.
	+	The code visitor handles the outputting of the C++ code. The C++ code is outputted to the file specified on the command line. The default filename is "rt_output.cc" if no output filename is specified.
	+
	+	The scope visitor has the same structure as the code visitor, but checks for different things. The scope visitor has a list of symbol tables that keeps track of the variables declared in each scope. The list works as a stack, with each element being a symbol table that maps symbol names to a declarable object. When a new scope is entered, a new table is pushed onto the stack and when the scope is left, the top table is popped off the stack. If an identifier is referenced that is not declared in the RTSync scope, a warning message is displayed to the user. The compiler does not fail because it is possible that this identifier is declared outside of the RTSync scope and is a C++ global variable or function. It is not critical for the RTSync compiler to fail on this error, since the error will be caught by the C++ compiler if the identifier is not declared at all.
	+
	+	The other responsibility of the scope visitor is to type-check expressions. Each expression has a type that is calculated depending on what is in the expression. If there is a mix of incompatible types then the compiler prints out an error and compilation fails. There is a function that compares two types

rtsync_-_timing_graph_generation

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:23:18+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	The compiler works in a visitor pattern, the codevisitor object moves around the syntax tree and parses each node differently.

	+	When the compiler reaches a fun_decl_node, or a node in which a method for an actor is declared, a <method> block is generated in the graph information file (which after debugging is done will be replaced with a string stream).
	+
	+	In each method, calls to other methods are recorded in the graph. A list of the scope expressions in which the call is made is recorded (ie. if the call is in an if statement, then the conditional expression is recorded). After this is listed, the actor and method names are recorded as a call.
	+
	+	Synchronizers are recorded in a similar fashion, except they are recorded in a <sync> block.
	+
	+	The graph information is then parsed by a "sanity checker" which tests the graph for timing violations. It is not possible to check for all timing violations at compile time, but in the case that the maximum and minimum time constraints of a synchronizer are equal to functions f and g respectively and f < g for all combinations of values for the independent variables of f and g, then there will always be a timing violation for this synchronizer. For example, if:
	+
	+	f(y) = y + 1000
	+	g(y) = y + 2000
	+
	+	then we have a timing violation for all values of y that may be passed to this function. Currently the sanity checker does not check for such a complex constraint, it only works if f and g are constant. A math library that can simplify an equation of the form f < g would be able to determine whether there is a definite timing violation or not. However if the simplified version of this equation contains variables which may result in this equality being true depending on the values, then there is not a definite timing violation.
	+
	+	====== The Sanity Checker ======
	+
	+	The sanity checker sets up a call graph that lists the calls made from each method, as well as a cost graph in which the nodes of the graph are the various methods and the edges are the costs to call each method. Since time constraints may be directed, the graph is also directed.
	+
	+	After the graph is constructed, a matrix of edges is created. An edge represents two values, a minimum constraint value (which we will call min) and a maximum constraint value (which we will call max). Most edges in the graph are regular edges that are not constrained (the minimum value is set to zero and the maximum value is set to infinity).
	+
	+	Edges may have three states:
	+
	+	* Null state: No edge exists here.
	+	* Unknown state: An edge exists, but the constraints cannot be verified.
	+	* Normal state:An edge exists with normal constraints.
	+
	+	Since the edges are in a matrix, there must be ways to add or multiply them together. Here is a description of how these operations are performed:
	+
	+	* Addition: z = x + y: If either x or y is in an unknown state, then z is in an unknown state. Otherwise, if both x and y are in a null state, then z is also in a null state. Regardless of states, the constraint values of z are as follows:<code>
	+	z.min = min(x.min, y.min)
	+	z.max = max(x.max, y.max)</code>
	+
	+	* Multiplication: z = x * y: If either x or y is in a null state, then z is in a null state. The same goes for if x or y are in an unknown state. If both are normal, then the constraint values of z are as follows:<code>
	+	z.min = x.min + y.min
	+	z.max = x.max + y.max</code> Note that this is normal integer arithmetic, if either operand is equal to infinity, then the sum is equal to infinity.
	+
	+	In the matrix, the cost of an edge (a, b) that goes from node a to node b is at location M[a][b]. The cost along the diagonal is set to an impossible cost.
	+
	+	After the matrix is created, two more matrices are created that are clones of the first matrix, called A. These two matrices are the result matrix, R, and the incremental matrix, I. The sanity checker then iterates over the result matrix and sets any edge that is not normal to an impossible state (min = infinity, max = 0).
	+
	+	The sanity checker then goes into a loop that iterates k times, where k is equal to the number of nodes in the graph. During each iteration, A is set to A * I. Then, for all A[i][j].min < R[i][j].min, R[i][j].min is set to A[i][j].min and for all A[i][j].max > R[i][j].max, R[i][j].max is set to A[i][j].max.
	+
	+	There is a problem with this method in that indirect max constraints may grow unboundedly due to loops. The sanity checker finds the loops in the graph by setting A = A^2 after all the iterations. If a max constraint is still increasing at this point, we have gone past k iterations and so this constraint must be in a cycle. Since this is growing without bounds, we set the max constraint in R equal to infinity.
	+
	+	Finally, the sanity checker scans the global constraints for inconsistencies or impracticalities. An inconsistencies is when the minimum constraint is greater than the maximum constraint and an impracticality is when they are equal.

rtsync_tutorial_1_-_an_overview_of_rtsync

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T22:54:43+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	As technology progresses in the world, standard computer programs cannot easily perform the tasks that problems require. Computer programs take a certain amount of time to do their computations and sometimes this time is not a realistic timeframe for the real world. A system with stricter timing constraints is required for such a problem. An example of such a problem is a computer program that is driving a car. If the program cannot recognize that it is about to drive into a tree before it hits the tree, then it is not a very useful program. However if this same program sees a turn in the road up ahead, realizes the turn is there immediately and immediately turns before it actually gets to the turn, this is also not especially desirable.

	+	It is possible for a computer program to program these time constraints using a standard language, however it would be much more efficient for a programmer to use a language that has these constructs already built-in. RTSync provides this with a system of actors and synchronizers, while keeping the familiar syntax of C++.
	+
	+	The system can be thought of as a graph where the nodes of the graph are the actors and the edges of the graph are the synchronizers. This is similar to an object-oriented construct, the actors are analogous to the objects in an object-oriented language. The difference here is the presence of synchronizers that handle the method calls between actors. In object-oriented languages, the method calls are not as constrained as they are under RTSync. A synchronizer can enable/disable methods, execute code upon certain method calls, and perform time-constraining actions to allow the method calls to follow a real-time pattern.
	+
	+	Another task that many languages cannot inherently do is run in a distributed fashion. A program that can run concurrently on several computer has major performance benefits over a program that is only running on one computer. RTSync also allows for distributed programs. When an actor calls a method of another actor, the other actor does not need to be on the same computer as the actor that is calling the method. RTSync manages the networking through it's run-time environment. The programmer does not need to know much about networking to do this, they simply need to provide an IP address and a port that connects to a computer that is currently running the program.

rtsync_tutorial_2_-_an_introduction

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T22:58:00+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	Here we will create a simple program using RTSync. In order to program in RTSync, a knowledge of C++ is required. RTSync is not a whole language of it's own, instead it is an extension to C++.
	+
	+	To install RTSync, run the command "make install" after extracting the tarball.
	+
	+	After installing the compiler, it is time to make a program using RTSync. Here is a skeleton for the first program:
	+
	+	#include <iostream>
	+	using namespace std;
	+
	+	void print(string &s)
	+	{
	+	cout << s << endl;
	+	}
	+
	+	actor A{
	+	init
	+	{
	+	/* nothing to do in the init block */
	+	}
	+
	+	a()
	+	{
	+	/* print something out to the screen */
	+	print("Hello, world!");
	+	}
	+	}
	+
	+	int main()
	+	{
	+	/* start up the RTSync system */
	+	rt_start("A", "a");
	+	}
	+
	+	So what does this code do? Some of the code is recognizable as C++ code. The actor block creates an actor called A with one method, a(). The init block is required for all actors, even if it does not do anything. The method a() prints out the string "Hello, world!" to the console. Note that in RTSync, methods do not have a return value. Also the print function is required since the RTSync compiler does not currently recognize cout as anything, but it will recognize print as an external function call. Also note that the comments follow the C format (/* ... */) instead of the C++ format. RTSync does not currently support C++ comments.
	+
	+	The main function has one simple line, a call to a function rt_start(). This function is generated by the compiler and handles the internal workings of RTSync, connecting to other computers for a distributed system and beginning the real-time system. The two parameters for the function are the actor's name, and the method to call.
	+

rtsync_tutorial_3_-_variables_and_flow_constraints

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:00:59+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	Anything outside of an actor or synchronizer block is treated as normal C++ code. As an extension to C++, RTSync tries to keep the functionality of C++ while added something new. Inside the actor/synchonizer blocks however, the code is not exactly the same as in C++. The only types of variables allowed are integers, floating point numbers, strings and arrays.

	+	Variables can either be a member variable of an actor or a local variable in a method. Declarations follow a C-style pattern, where all the variables must be declared at the start of the method. The only difference is that variables may be declared inside a loop or an if statement, so long as the declaration comes before any other lines.
	+
	+	The flow control statements that are allowed in RTSync are while loops and if statements. No for loops or do...while loops are allowed. Other than that, these statements have the same structure as they normally would in C++. Here is a simple example of a program using loops and variables:
	+
	+	#include <iostream>
	+	using namespace std;
	+
	+	actor A
	+	{
	+	int i;
	+
	+	init
	+	{
	+	i = 0;
	+	}
	+
	+	a(int n)
	+	{
	+	if(n < 0)
	+	{
	+	n = -n;
	+	}
	+	while(i < n)
	+	{
	+	cout <<i <<endl;
	+	i = i + 1;
	+	}
	+	i = 0;
	+	}
	+
	+	start()
	+	{
	+	a(5);
	+	}
	+	}
	+
	+	int main()
	+	{
	+	rt_start("A", "start");
	+	}
	+
	+	As can be seen here, there are several new additions. We have a member variable, i, a parameter to a method, and several flow control statements. The program begins by calling the start() method of A, which then calls the method a(). Parameters cannot be passed using the rt_start() function, so a simple method like start() may be used instead to pass the parameters. So in this program we have the method a() that checks the parameter n to see if it is less than zero and if it is, then it inverts it. Then it iterates n times and prints the numbers to the screen. Note that the line:
	+
	+	i = i + 1;
	+
	+	is used instead of i++. The ++, --, +=, etc. operators are not currently supported in RTSync.

rtsync_tutorial_4_-_actors

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:02:37+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	Up until now, the only examples have been those with only one actor. Most practical programs written in RTSync will not only use one actor, but several working together simulaneously. Here is an example of a program using multiple actors:

	+	#include <iostream>
	+	using namespace std;
	+
	+	void print(string &s)
	+	{
	+	cout << s << endl;
	+	}
	+
	+	actor A
	+	{
	+	init
	+	{
	+	/* do nothing */
	+	}
	+
	+	a()
	+	{
	+	/* call a method of B */
	+	B.b(50);
	+	/* print finished message */
	+	print("Method A.a() finished.");
	+	}
	+	}
	+
	+	actor B
	+	{
	+	int i;
	+
	+	init
	+	{
	+	i = 2;
	+	}
	+
	+	b(int n)
	+	{
	+	/* do some random calculation */
	+	while(i < n)
	+	{
	+	i = i + 1;
	+	}
	+	/* print finished message */
	+	print("Method B.b() finished.");
	+	}
	+	}
	+
	+	int main()
	+	{
	+	rt_start("A", "a");
	+	}
	+
	+	Here we have a second actor B introduced. This program looks quite similar to that in the last tutorial. This is done to illustrate a simple point. From C++ knowledge, one would expect that when the program finished, the console output would look something like this:
	+
	+	Method B.b() finished.
	+	Method A.a() finished.
	+
	+	However this is not necessarily the case. It is possible that this may be what happens, however unlike C++, Java or several other languages, RTSync does not halt in a() when b() is called. Instead of waiting for b() to finish, a() will then execute the next line, with b() running on a new thread. In order to understand real-time programming, one must understand multithreaded programs. In a program it is possible to have multiple threads running at once. For example, an instant messenger program can have multiple conversations in separate windows at once. Each one of these may have it's own thread to handle interactions with it. Another thread may then be communicating with the server to retrieve messages in one conversation while the user is typing into a different conversation. RTSync handles this in a similar fashion, where each actor is running simulaneously and communicates with one another by messages. Instead of thinking of the line
	+
	+	B.b(50);
	+
	+	as a method call with a parameter 50, it can be thought of as a message to B saying to run its method b() with the parameter 50.
	+
	+	There is a way for one method to wait for another method to finish, and that is by using the sync keyword. Here is an example:
	+
	+	actor A
	+	{
	+	/* anything else in here */
	+
	+	a()
	+	{
	+	sync B.b();
	+	print("Method A.a() finished.");
	+	}
	+	}
	+
	+	In this case, A.a() would wait until B.b() finished, guaranteed.
	+
	+	One other thing to note with this example is that the actor B is declared after the actor A. Normally in C++ if something makes a reference to something that has not been defined yet, the compiler gives an error. In RTSync, actors do not need to be declared before they can have messages passed to them by other actors. There is a reason for this, which will be discussed in much more detail in a later tutorial.

rtsync_tutorial_5_-_synchronizers

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:04:15+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	So far this tutorial has not gone over any of the aspects of the language that are devoted to maintaining real-time constraints. Synchronizers are used in RTSync to uphold these constraints. A synchronizer is set up similar to an actor, but it does not have any methods. Instead there are four blocks: initialization, constraints, triggers and exceptions. Here is a skeleton of a synchronizer declaration:

	+	synchronizer synchronizer_name
	+	{
	+	variable declarations
	+
	+	init( actor pairs to synchronize )
	+	{
	+	initialization code
	+	}
	+
	+	constraints
	+	{
	+	timing constraints
	+	}
	+
	+	trigger
	+	{
	+	synchronization actions
	+	}
	+
	+	exception
	+	{
	+	what to do on a timing violation
	+	}
	+	}
	+
	+	All four of these sections must be in place, otherwise there is an error. So what are these four blocks? That is what will be discussed now.
	+
	+	The synchronizer is what handles the messages between actors. So in order to see which messages to intercept, the synchronizer must be told which actors to monitor. In the init block, there is the initialization code that is run when the synchronizer is created, but also in the parentheses after the init keyword the actor pairs to synchronize are specified. An actor pair in this declaration list is specified using the following syntax:
	+
	+	actor1 <-> actor2
	+
	+	The order that the two actors come in does not have any significance. Any number of pairs may be synchronized by one synchronizer, separated by commas.
	+
	+	The constraints section handles the timing constraints for messages. There are two types of constraints: maximum constraints and minimum constraints. The maximum constraints can be thought of as a sort of deadline for a message (the time by which the message must be sent) and the minimum constraint is the earliest time that a message will be sent. Given minimum constraints, it is possible for a long period of time to pass between the time when the first actor sends a message and the time when the method is actually received by the second actor. The syntax of these two constraints is as follows:
	+
	+	min actor1.method1 -> actor2.method2 = some_expression;
	+	max actor1.method1 -> actor2.method2 = another_expression;
	+
	+	The min statement here means that when actor1.method1() calls actor2.method2(), an amount of time equal to some_expression must pass before actor2 actually gets the message. The max statement here means that when actor1.method1() calls actor2.method2(), if an amount of time passes equal to another_expression before the message actually gets to actor2 then an exception is thrown (hence the exception block). However, note that if some_expression is always greater than another_expression, then you will always have a timing violation.
	+
	+	The trigger and exception blocks are described in the next tutorial.

rtsync_tutorial_6_-_more_on_synchronizers

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:05:54+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	In the last tutorial, synchronizers were introduced and two of their blocks were described. The other two blocks contained in a synchronizer are the trigger and exception blocks.

	+	The trigger block is a rather complex block. Here, methods can be enabled or disabled, or event-triggered code can be called. There are three types of statements that can be put in the trigger section: enable statements, disable statements and action statements.
	+
	+	Enable and disable statements are fairly simplistic. These statements can enable or disable methods according to some condition. The syntax of these statements is as follows:
	+
	+	enable actor.method when conditional_expression1;
	+	disable actor.method when conditional_expression2;
	+
	+	As soon as conditional_expression1 is true, the method will be enabled (by default all methods are enabled) and as soon as conditional_expression2 is true, the method will be disabled. Remember that once a method is disabled/enabled, the method will remain that way unless explicitly changed. This means that when conditional_expression2 becomes true, actor.method() will be disabled, but it won't actually become enabled again when conditional_expression becomes false unless an enable statement is created to tell the synchronizer to re-enable the method.
	+
	+	A problem with disabling methods is if one method tries to make a synchronized call (a call using the sync keyword) to a disabled method, it will block until the method is enabled again and finishes running. This can cause some unpredictable results, as some actors will then stall when they should be running.
	+
	+	The third statement that can be used in the trigger block is the action statement. This statement simply executes some code whenever a particular method is called. This allows for the synchronizer to take some action when a particular method is called. The syntax for the statement is as follows:
	+
	+	action(actor.method)
	+	{
	+	executable_code
	+	}
	+
	+	Whenever actor.method() is called, executable_code is executed. Why is this needed, if executable_code can just be placed in actor.method()? One reason this is needed is that actor.method() does not have access to the synchronizer's variables, so for example if the synchronizer would like to keep track of how many times this method has been called, it can keep a member variable here and increment the variable each time this action block is executed (and possibly disabling the method or enabling another method when the variable hits a certain value, or do something else).
	+
	+	The fourth block of the synchronizers is the exception block. This is a very simple block, with a very simple syntax:
	+
	+	exception{
	+	exception_code
	+	return_statement
	+	}
	+
	+	When a timing violation occurs in this synchronizer, exception_code is executed. A timing violation occurs when a message being sent is not sent before the deadline has passed (the car has crashed into a tree, or missed the turn).
	+
	+	The one difference between the exception block and other blocks is that the exception block will return a value depending on what the system should do when the exception is thrown. The exception block may return one of three values:
	+
	+	TERMINATE: Terminate the entire system, the program on all computers will be shut down.\\
	+	KILLNODE: Terminate the system on this computer, systems on other computers are unaffected.\\
	+	CONTINUE: Continue running the program on all systems.
	+
	+	If no return statement is specified, the default return value is TERMINATE.

rtsync_tutorial_7_-_global_synchronizers

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:07:23+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	Global Synchronizers are very similar to regular synchronizers, except that they are not designed to be used for point-to-point synchronization as regular synchronizers are, but for a general synchronization. They are used for synchronizing methods inside an actor, or for general scheduling tasks (ie. starting this method at a certain time, starting another method at another time, etc.)

	+	The structure of a global synchronizer is exactly the same as a normal synchronizer, but with one difference: global synchronizers do not have a name. This means that there can only be one global synchronizer per node (one global synchronizer per instance of a program running on a computer). The syntax is as follows:
	+
	+	global
	+	{
	+	variable declarations
	+
	+	init( actor pairs to synchronize )
	+	{
	+	initialization code
	+	}
	+
	+	constraints
	+	{
	+	timing constraints
	+	}
	+
	+	triggers
	+	{
	+	synchronization actions
	+	}
	+
	+	exception
	+	{
	+	what to do on a timing violation
	+	}
	+	}
	+
	+	This is exactly the same as a synchronizer declaration, except for the first line it is simply the global keyword instead of the synchronizer keyword followed by a name.

rtsync_tutorial_8_-_distributed_applications

Anonymous (anonymous@undisclosed.example.com) — 2012-05-09T23:08:20+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	Another main aspect of RTSync is it's ability to handle distributed applications. A distributed application is one that runs simultaneously on multiple machines at once. This involves somewhat complicated network synchronization for data sharing and message passing. Fortunately, RTSync handles these complications internally, so the programmer does not need to worry about them. Actors can be located on any machine in the system and still be accessible by any machine. In fact, when one actor calls a method of another actor, they don't even need to know which machine the other is running on! This is all taken care of by RTSync's postmaster that runs internally.

	+	In a previous tutorial, it was said that actors do not need to be declared in any particular order. So if actor A calls a method of actor B, it doesn't matter which was declared first. In fact, actor B does not even need to be declared in the file, and the compiler will not print out an error. When the program runs, the message will be sent to actor B, but if actor B is not in the local program then the postmaster will send it over the network to find a connected program that has an actor B. If none is found, then the postmaster will hold on to the message until an actor B enters the system (note that timing exceptions may occur if actor B joins too late).
	+
	+	How does this all work from the programmer's perspective? For this, the rt_start() function must be looked at again. There are actually two prototypes for this function:
	+
	+	void rt_start(actor_name, method_name, server_port = 6127,
	+	host = 0, host_port = 6127);
	+	void rt_start(server_port = 6127, host = 0, host_port = 6127);
	+
	+	The first is the familiar one, with a default host set to zero. This means that the postmaster will not try to connect to any other computers. If a host IP address is passed (in the form of a string), then the postmaster will connect to the computer at that IP and then will become connected to all the other computers in the system. The postmaster will then run the specified method.
	+
	+	The second prototype is a prototype for a postmaster that does not start a method when it begins. This simply connects to the main system and then waits for any messages to be sent to this postmaster. Once a message is received, the actors on the machine will begin to run.

rtsync

Anonymous (anonymous@undisclosed.example.com) — 2015-05-03T21:17:07+00:00

run-time_solutions_to_the_stack_overflow_problem

Anonymous (anonymous@undisclosed.example.com) — 2024-10-26T17:30:54+00:00

Fri 13 May 2016 9:12 am -0400		current
Line 3:		Line 3:
	This work is described in the following publication: //Toward Preventing Stack Overflow Using Kernel Properties// (by Benjamin Teissier and Stefan D. Bruda, in Proceedings of the 9th International Conference on Software Engineering and Applications, August 2014, Vienna, Austria).		This work is described in the following publication: //Toward Preventing Stack Overflow Using Kernel Properties// (by Benjamin Teissier and Stefan D. Bruda, in Proceedings of the 9th International Conference on Software Engineering and Applications, August 2014, Vienna, Austria).

-	An [[http://www.ubishops.ca/wp-content/uploads/bucstr-2014-001.pdf\|extended version of this publication]] is available locally. The {{:part:papers:teissier-vm.tar.gz\|code described in the paper}} is also available.	+	An [[http://www.ubishops.ca/wp-content/uploads/bucstr-2014-001.pdf\|extended version of this publication]] is available locally. The {{:part:papers:teissier-vm.tar.gz\|code described in the paper}} is also available under the [[https://www.gnu.org/licenses/\|GNU General Public License]].

	This solution is implemented at the kernel level. A system implementing our method will patch all programs at launch time so that every call and ret will also perform an appropriate system call. As a consequence of the system call attached to calls a copy of the new top of the stack is stored in kernel space. This copy is then compared with the top of the stack stack through the system call associated to ret. This solution is a good proof of concept but is not production ready (see the paper above for a discussion on the matter).		This solution is implemented at the kernel level. A system implementing our method will patch all programs at launch time so that every call and ret will also perform an appropriate system call. As a consequence of the system call attached to calls a copy of the new top of the stack is stored in kernel space. This copy is then compared with the top of the stack stack through the system call associated to ret. This solution is a good proof of concept but is not production ready (see the paper above for a discussion on the matter).
Line 23:		Line 23:
	We also include a fast version that operates in effectively the same manner with the only difference being that it will only verify the stack pointer whenever a write system call is intercepted. This is an approach that attempts to solve the issue of time due to the fact that the full version will check every single instruction and thus takes a significant ammount of time. In order to justify this approach we argue that in practice, we were able to detect that write system calls were issued at key points during the stack overflow and thus, our fast version works under a specific set of conditions.This is further detailed in the thesis.		We also include a fast version that operates in effectively the same manner with the only difference being that it will only verify the stack pointer whenever a write system call is intercepted. This is an approach that attempts to solve the issue of time due to the fact that the full version will check every single instruction and thus takes a significant ammount of time. In order to justify this approach we argue that in practice, we were able to detect that write system calls were issued at key points during the stack overflow and thus, our fast version works under a specific set of conditions.This is further detailed in the thesis.
	==== Files ====		==== Files ====
-	The {{:part:papers:stackintegrityattacks.tar.gz\|complete source code}} is available. The following are the executable programs that constitute our solution:	+	The {{:part:papers:stackintegrityattacks.tar.gz\|complete source code}} is available under the [[https://www.gnu.org/licenses/\|GNU General Public License]]. The following are the executable programs that constitute our solution:

	^ Name ^ Description ^		^ Name ^ Description ^

size_matters_-_logarithmic_space_is_real_time

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:43:21+00:00

Wed 9 May 2012 7:37 pm -0400		current
Line 1:		Line 1:
-	By Stefan D Bruda and Selim G. Akl. A {{:papers:logspace-s3.pdf\|preliminary version}} of the paper published in the International Journal of Computers and Applications is available. It also contains material from On the relation between parallel real-time computations and logarithmic space (PDCS 2002) and The characterization of parallel real-time optimization problems (16th Annual International Symposium on High Performance Computing Systems and Applications 2002).	+	By Stefan D Bruda and Selim G. Akl. A {{:part:papers:logspace-s3.pdf\|preliminary version}} of the paper published in the International Journal of Computers and Applications is available. It also contains material from __On the relation between parallel real-time computations and logarithmic space__ (PDCS 2002) and __The characterization of parallel real-time optimization problems__ (16th Annual International Symposium on High Performance Computing Systems and Applications 2002).

-	A more preliminary version is also available; this version contains a number of flaws in the presentation of the main matter, but also supplementary material. Thus the overlapping material is better reviewed using the first document, while one should review the extra material from this second document.	+	A {{:part:papers:nlogspace.pdf\|more preliminary version}} is also available; this version contains a number of flaws in the presentation of the main matter, but also supplementary material. Thus the overlapping material is better reviewed using the first document, while one should review the extra material from this second document.

sublinear_space_real-time_turing_machines_cannot_count

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:45:29+00:00

Thu 10 May 2012 3:51 pm -0400		current
Line 1:		Line 1:
-	by Stefan D Bruda, in Proceedings of the 8th International Conference on Information Technology: New Generations, April 2011, Las Vegas, NV. A [[http://cs.ubishops.ca/techreps/bucstr-2010-001.pdf\|preliminary version]] is available.	+	by Stefan D Bruda, in Proceedings of the 8th International Conference on
		+	Information Technology: New Generations, April 2011, Las Vegas, NV. A
		+	[[http://www.ubishops.ca/wp-content/uploads/bucstr-2010-001.pdf\|preliminary version]] is available.

the_characterization_of_data-accumulating_algorithms

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:53:57+00:00

Thu 23 Apr 2026 1:11 am -0400		current
Line 1:		Line 1:
		+	{{:part:papers:data-acum2.pdf\|This version}} is almost identical to the paper published in Theory of Computing Systems (and includes the IPDPS paper).

the_graph_accessibility_problem_and_the_universality_of_the_collision_crcw_conflict_resolution_rule

Anonymous (anonymous@undisclosed.example.com) — 2012-05-13T20:54:44+00:00

Thu 23 Apr 2026 1:11 am -0400		current
Line 1:		Line 1:
		+	By Stefan D. Bruda. {{:part:papers:reconf.pdf\|This paper}} contains most of the material from __The Graph Accessibility Problem and the Universality of the Collision CRCW Conflict Resolution Rule__ (WSEAS Transactions on Computers) and from __The Characterization of Constant Time Computations and the Universality of Collision Rule on Models with Reconfigurable Buses__ (10th WSEAS International Conference on Computers, 2006).

unrestricted_and_disjoint_operations_over_multi-stack_visibly_pushdown_languages

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:47:04+00:00

Thu 10 May 2012 3:49 pm -0400		current
Line 1:		Line 1:
-	by Stefan D Bruda and Md. Tawhid Bin Waez, in Proceedings of the 6th International Conference on Software and Data Technologies, July 2011, Seville, Spain. A [[http://cs.ubishops.ca/techreps/bucstr-2009-001.pdf\|preliminary version]] is available.	+	by Stefan D Bruda and Md. Tawhid Bin Waez, in Proceedings of the 6th
		+	International Conference on Software and Data Technologies, July 2011,
		+	Seville, Spain. A
		+	[[http://www.ubishops.ca/wp-content/uploads/bucstr-2009-001.pdf\|preliminary version]] is available.

why_languages_generated_by_context-free_parallel_communicating_grammar_systems_are_not_linear_space

Anonymous (anonymous@undisclosed.example.com) — 2015-09-30T15:48:06+00:00

Thu 23 Apr 2026 1:11 am -0400	current
Line 1:	Line 1:
	+	by Mary Sarah Ruth Wilkin and Stefan D. Bruda, in Proceedings of the 14th International Conference on Applied Computer Science, January 2014, Cambridge, MA.
	+
	+	This paper only contains an intuitive example and not the actual
	+	counterexample. The latter can be found in the
	+	[[http://www.ubishops.ca/wp-content/uploads/bucstr-2014-002.pdf\|extended version]] available as a technical report.

Sun 13 May 2012 5:08 pm -0400		current
Line 1:		Line 1:
	====== A Distributed Real-Time Programming Languages for Commodity POSIX Systems ======		====== A Distributed Real-Time Programming Languages for Commodity POSIX Systems ======
		+
		+	Note: //The system is not actively maintained at this time. Maintenance might resume in the future but this is not guaranteed (depends between other things on interest from the outside world).//

	The RTSync page contains material described in __Distributed, Real-Time Programming on Commodity POSIX Systems: A Preliminary Report__ (ISPDC 2006) and __Distributed, Real-Time Programming Based on a Formal Semantics on Commodity POSIX Systems with no In-Kernel Real-Time Support__ (RRA 2008).		The RTSync page contains material described in __Distributed, Real-Time Programming on Commodity POSIX Systems: A Preliminary Report__ (ISPDC 2006) and __Distributed, Real-Time Programming Based on a Formal Semantics on Commodity POSIX Systems with no In-Kernel Real-Time Support__ (RRA 2008).
Line 7:		Line 9:
	* The current version is {{:part:papers:rtsync-0.1-rc4.tar.gz\|rtsync-0.1-rc4}}		* The current version is {{:part:papers:rtsync-0.1-rc4.tar.gz\|rtsync-0.1-rc4}}

-	* The [[http://part.bruda.ca/rtsync/api-doc-0.1-rc4/\|associated API documentation]] is available.	+	* The [[https://part.bruda.ca/rtsync/api-doc-0.1-rc4/\|associated API documentation]] is available.

	* Tutorials (preliminary form):		* Tutorials (preliminary form):
-	* [[http://part.bruda.ca/papers/rtsync_tutorial_1_-_an_overview_of_rtsync\|RTSync Tutorial 1 - An Overview of RTSync]]	+	* [[https://part.bruda.ca/papers/rtsync_tutorial_1_-_an_overview_of_rtsync\|RTSync Tutorial 1 - An Overview of RTSync]]
-	* [[http://part.bruda.ca/papers/rtsync_tutorial_2_-_an_introduction\|RTSync Tutorial 2 - An Introduction]]	+	* [[https://part.bruda.ca/papers/rtsync_tutorial_2_-_an_introduction\|RTSync Tutorial 2 - An Introduction]]
-	* [[http://part.bruda.ca/papers/rtsync_tutorial_3_-_variables_and_flow_constraints\|RTSync Tutorial 3 - Variables and Flow Constraints]]	+	* [[https://part.bruda.ca/papers/rtsync_tutorial_3_-_variables_and_flow_constraints\|RTSync Tutorial 3 - Variables and Flow Constraints]]
-	* [[http://part.bruda.ca/papers/rtsync_tutorial_4_-_actors\|RTSync Tutorial 4 - Actors]]	+	* [[https://part.bruda.ca/papers/rtsync_tutorial_4_-_actors\|RTSync Tutorial 4 - Actors]]
-	* [[http://part.bruda.ca/papers/rtsync_tutorial_5_-_synchronizers\|RTSync Tutorial 5 - Synchronizers]]	+	* [[https://part.bruda.ca/papers/rtsync_tutorial_5_-_synchronizers\|RTSync Tutorial 5 - Synchronizers]]
-	* [[http://part.bruda.ca/papers/rtsync_tutorial_6_-_more_on_synchronizers\|RTSync Tutorial 6 - More On Synchronizers]]	+	* [[https://part.bruda.ca/papers/rtsync_tutorial_6_-_more_on_synchronizers\|RTSync Tutorial 6 - More On Synchronizers]]
-	* [[http://part.bruda.ca/papers/rtsync_tutorial_7_-_global_synchronizers\|RTSync Tutorial 7 - Global Synchronizers]]	+	* [[https://part.bruda.ca/papers/rtsync_tutorial_7_-_global_synchronizers\|RTSync Tutorial 7 - Global Synchronizers]]
-	* [[http://part.bruda.ca/papers/rtsync_tutorial_8_-_distributed_applications\|RTSync Tutorial 8 - Distributed Applications]]	+	* [[https://part.bruda.ca/papers/rtsync_tutorial_8_-_distributed_applications\|RTSync Tutorial 8 - Distributed Applications]]

	* Workings of the RTSync compiler and run-time environment:		* Workings of the RTSync compiler and run-time environment:
-	* [[http://part.bruda.ca/papers/rtsync_-_overview\|RTSync - Overview]]	+	* [[https://part.bruda.ca/papers/rtsync_-_overview\|RTSync - Overview]]
-	* [[http://part.bruda.ca/papers/rtsync_-_the_compiler\|RTSync - The Compiler]]	+	* [[https://part.bruda.ca/papers/rtsync_-_the_compiler\|RTSync - The Compiler]]
-	* [[http://part.bruda.ca/papers/rtsync_-_timing_graph_generation\|RTSync - Timing Graph Generation]]	+	* [[https://part.bruda.ca/papers/rtsync_-_timing_graph_generation\|RTSync - Timing Graph Generation]]
	* __RTSync - The Postmaster__		* __RTSync - The Postmaster__

-	Note: //The system is not actively maintained at this time.//