Задани на лабораторные работы. ПРК / Professional Microsoft Robotics Developer Studio

www.it-ebooks.info

Chapter 2: Concurrency and Coordination Runtime (CCR)

It appears that this fancy version of Wait is not a solution to the problem of blocking a thread — it still has the same effect as Thread.Sleep. The subtle issue here is that if Wait is called while another Wait is active, then two threads are blocked and there are no threads left to execute the delegates and wake up the waiting threads. The main loop calls Wait after executing your selection, and then the Spawn example also executes Wait.

You must be very careful not to deadlock the CCR by soaking up all of the threads. If you know that one of your threads will block, and there is no easy way around it, then you can explicitly specify a separate dispatcher and the number of threads to use on your service.

For reviewing this chapter, many thanks to George Chrysanthakopoulos, lead developer for MRDS, who says that “yield is your friend.”

Inside an iterator, it is very easy to create a delay directly by using the TimeoutPort in a yield return:

// Wait for some time

yield return Arbiter.Receive( false,

TimeoutPort(timeDelay), delegate(DateTime timeout) { }

);

Timers set up in this way are not very reliable because they use CLR timers. There is a fair amount of variation in the time intervals that elapse. This should be corrected with new timers in version 2.0 of MRDS. In the meantime, you can search the forum for ways to work around this problem if you need highly accurate timers or timers for very short time periods. You need to use a CcrStopwatch with V1.5. You can find some threads on this topic in the MRDS discussion forum.

Periodic Events

Executing code periodically is simply a matter of using the TimeoutPort with the persist parameter set to true and specifying the handler to call. Note that the handler must accept a DateTime

parameter. This approach results in the handler being called repeatedly. If the handler cannot perform its processing within the specified time period, then the messages back up and the handler will be flat-out running all the time.

Another approach that is probably better is for the handler to call itself back when it has finished processing. For example, the following handler activates a new receiver to call itself as the last statement in the routine, but it is a nonpersistent receiver:

static int TimerCounter = 0;

// A handler that calls itself periodically void PeriodicTimerExample(DateTime dt)

{

int timeDelay = 1000;

TimerCounter++;

if (TimerCounter > 10)

(continued)

73

www.it-ebooks.info

Part I: Robotics Developer Studio Fundamentals

(continued)

return;

Console.WriteLine(“Tick {0} ...”, TimerCounter);

// Wait for some time Activate(Arbiter.Receive(

false,

TimeoutPort(timeDelay),

PeriodicTimerExample));

}

To get the process started, you must set up an initial receiver. In the following code, the timeout is set to only 10 milliseconds because this is just to get the process going. Note also that the TimerCounter is reset to zero first because the timer handler should only run 10 times:

// Reset the counter and kick off the timer TimerCounter = 0;

Activate(Arbiter.Receive(false, TimeoutPort(10), PeriodicTimerExample));

When you run this code by selecting Periodic Timer in CCRExamples, the output might look like the following:

Tick 1 ...

Select from the following:

0 = Exit

1 = Spawn

2 = Task From Handler

3 = Task From Iterator

4 = SpawnIterator

5 = Post and Test

6 = Receive

7 = Choice

8 = Join

9 = MultipleItemReceive

10 = MultiplePortReceive

11 = Periodic Timer

12 = Causality

Enter a number: Tick 2 ...

Tick 3 ...

Tick 4 ...

Tick 5 ...

Tick 6 ...

Tick 7 ...

Tick 8 ...

Tick 9 ...

Tick 10 ...

This might not seem very exciting, but you can make another selection from the menu while the timer is ticking. See what happens then! Do you run out of threads? If so, uncomment the ActivationSettings to give yourself six threads and try again.

74

www.it-ebooks.info

Chapter 2: Concurrency and Coordination Runtime (CCR)

You can improve the accuracy of a periodic timer by using the parameter, which is a timestamp. If the code remembers the timestamp from the previous invocation, it can subtract the two and figure out the amount of time that actually elapsed. The new delay for the next timeout can be adjusted so that the timer fires on schedule the next time. At least that is the theory — it isn’t always reliable.

Setting Limits with Timeouts

From time to time, you might want to execute an operation that might not succeed but for which there is no indication of failure. For example, if you send a request to a service that is hung, then you will never receive a reply. In this case, you want to use a timeout so that you don’t end up waiting forever.

Consider the following code fragment from the Lynx6Arm simulation in Chapter 8:

// Wait for notification or time out if nothing is received yield return Arbiter.Choice(

Arbiter.Receive(false,

TimeoutPort(DsspOperation.DefaultLongTimeSpan), delegate(DateTime dt)

{ LogError(“Timeout waiting for visual entity”); Shutdown(); }), Arbiter.Receive<simengine.InsertSimulationEntity>(false,

notificationTarget, delegate(simengine.InsertSimulationEntity ins)

{

_entity = (Lynx6ArmEntity)ins.Body;

})

);

The Choice waits on the TimeoutPort and the Simulator notification port. If the simulation entity is successfully created, there is no problem. However, if it is not, the timeout will kick in.

Note that all DSS operations have a TimeSpan property that you can set before you post a request. This specifies the maximum amount of time to wait for a reply. If there is no response within that time period, then a Fault is generated automatically by DSS. This is an alternative approach.

Asynchronous I/O

Most of the robot implementations provided with MRDS use a serial port for communication. The .NET environment makes programming easy with the SerialPort class. However, serial ports normally operate asynchronously. It is not a good idea to tie up a CCR thread waiting for a read on a serial port, but sometimes this is your only option. (For example, look at the Hemisson robot in Chapter 17.)

Covering how to use a serial port is outside the scope of this chapter. You should look at some of the sample code in MRDS and also study Chapter 17. Be aware, however, that there are many different ways to implement serial communications.

The best example is probably in the Sick Laser Range Finder code. You can find this service in samples\ Sensors\SickLRF and you should look at SerialIOManager.cs, which defines a set of operations that it can perform (Open, Close, SetRate, Send) and has a public ResponsePort to which it posts received packets. External code can wait on the ResponsePort for messages, which will be either a Packet or an

Exception.

75

www.it-ebooks.info

Part I: Robotics Developer Studio Fundamentals

This approach of using two ports is a good way to isolate the asynchronous code. One port is used for sending commands, configuration parameters, and outgoing data, and the other port is used for receiving incoming data and errors. How the service works internally is irrelevant to the CCR.

Blocking I/O

For long operations that involve blocking I/O requests, such as writing a large file, it is not desirable to tie up a thread. In this case you can create a separate dispatcher and submit a task to it. Alternatively, create a CLR thread and allocate it exclusively for use with the I/O operations. This removes it from the CCR scheduling.

Note that when you create a service (which is covered in Chapter 3), you can specify that you want it to have its own dispatcher, as described earlier in this chapter. This takes it out of contention for threads in the main DSS thread pool. You can do this using an attribute at the top of your service, as shown in the following example:

[ActivationSettings(ShareDispatcher=false, ExecutionUnitsPerDispatcher=6)] [Contract(Contract.Identifier)]

public class CCRExamplesService : DsspServiceBase

{

...

Note that some blocking operations have Asynchronous Programming Model (APM) implementations that help with multi-threading. These are the classic begin/end operations that can be used with web requests (see the IPCamera.cs sample included in the MRDS distribution) or with file I/O. All that your code needs to do is create a port for signaling the completion of the asynchronous operation, execute the Begin method, and then post a message to this port in the End method (which runs asynchronously). Meanwhile, your CCR code can use a receiver to wait on the port.

This topic comes up again later in the section “Interoperation with Legacy Code.”

Throttling

A subtle way to enforce throttling is to set the number of threads to a small number on the dispatcher. Tasks will then pile up, waiting to execute, because not enough threads are available. Remember that you can apply policies to dispatcher queues that explicitly implement throttling strategies.

In Chapter 17, the code for the Hemisson Drive implements a throttling process for SetDrivePower requests by posting all requests to an internal port. There are several operations that you can use to change the drive power, and this “funneling” of the requests through a single port enables it to examine the queue and drop messages when required — a task that isn’t possible with the main interleave. This is necessary because serial communications with the Hemisson are very slow and must be done synchronously to avoid hanging the onboard monitor program. Recall that when you use a joystick to drive a robot, hundreds of requests can arrive in a short period of time.

76

www.it-ebooks.info

Chapter 2: Concurrency and Coordination Runtime (CCR)

Error Handling

You can, of course, still use structured exception handling with try/catch/finally statements. However, in a multi-threaded environment, it is possible for an error to occur in a different thread, and the error needs to be passed back to the original caller.

You have already seen examples of using a Choice to select either a valid response or a fault. This relies on the other service trapping any errors and generating a fault message.

If an exception occurs during the processing of a message in a DSS operation handler and you don’t have a try/catch, then DSS automatically converts the Exception object to a Fault and sends it back as the response.

Note that DSS includes a set of methods for tracing. In particular, you can use the LogError method to send a message to the console output of the DSS node. This is explained in Chapter 3. It is always a good idea to put calls to LogError in places where the error might be catastrophic.

It is also possible to output information to the MRDS command window using the Console.WriteLine method. This is not a good approach, but it might be better than nothing at all. Be aware, however, that writing to the console this way is a relatively slow process; and you should not use it inside a tight loop or it will slow down your service. Microsoft discourages the use of Console.WriteLine.

Causalities

The CCR defines an error handling approach called causalities. These are based on the concept that no matter how you nest operations, and regardless of whether they are asynchronous or not, there is some point in the past that is the root cause of the current execution stream.

Causality contexts are passed from a sender to a receiver and propagate from there to any further receivers that are invoked. They can even handle multiple exceptions, such as might be generated from a Join, for example. In this case, the causality will contain multiple items.

Here is the example code from CCRExamples. In order to see it working, you must start the program without the debugger; otherwise, the debugger will trap the exception and the causality won’t get a chance to handle it.

//Example of using a Causality

//NOTE: You must run this example without the Debugger!

//Otherwise the Debugger will trap the exception and you

//will not see the Causality working properly.

//

private void Causality()

{

using (Dispatcher d = new Dispatcher())

{

(continued)

77

www.it-ebooks.info

Part I: Robotics Developer Studio Fundamentals

(continued)

using (DispatcherQueue taskQ = new DispatcherQueue(“Causality Queue”, d))

{

Port<Exception> ep = new Port<Exception>(); Port<int> p = new Port<int>();

// Set up a causality for the current thread Dispatcher.AddCausality(new Causality(“Test”, ep));

Console.WriteLine(“Main thread: {0}”,

Thread.CurrentThread.ManagedThreadId);

//Set up a receiver that will generate an exception Arbiter.Activate(taskQ, Arbiter.Receive(false, p, CausalityExample));

//Post an item and the causality goes with it

p.Post(2);

Wait(500);

Exception e;

while (ep.Test(out e)) Console.WriteLine(“Exception: “ + e.Message);

}

}

}

// Receiver to execute with causality enabled private void CausalityExample(int num)

{

Console.WriteLine(“CausalityExample thread: {0}”, Thread.CurrentThread.ManagedThreadId);

Port<int> p = new Port<int>(); // Set up another receiver

Arbiter.Activate(Environment.TaskQueue, Arbiter.Receive(false, p,

// And now an anonymous delegate delegate(int n)

{

Console.WriteLine(“Anonymous method thread: {0}”, Thread.CurrentThread.ManagedThreadId);

// Can you spot the deliberate error? int i = 0; n = n / i;

}

));

// Post a message to activate the receiver p.Post(num);

}

The output from the preceding example might look as follows:

Main thread: 8

CausalityExample thread: 15

Anonymous method thread: 9

Exception: Attempted to divide by zero.

78

www.it-ebooks.info

Chapter 2: Concurrency and Coordination Runtime (CCR)

Notice that three different threads are involved here:

The main thread is the one that displays the exception message because it does not yield (it just sleeps).

The second thread is the receiver called CausalityExample, and it is deliberately run in a different dispatcher to illustrate the point.

The third thread is from the default dispatcher and is a delegate receiver inside

CausalityExample.

One other point to note about the preceding code is the use of a using statement to wrap all of the code in the first routine that uses the new dispatcher and dispatcher queue. This ensures that these are disposed of as soon as the block of code finishes executing, rather than waiting for the garbage collector. The other examples in CCRExamples didn’t bother with this, although they probably should have done so.

Success/Failure Ports

The next example shows how to use a SuccessFailurePort, which is a PortSet consisting of a SuccessResult and an Exception. In this case, the handler is the GetHandler from the Lynx6Arm service in Chapter 15. The overall approach here is to call a method that returns a port and then branch based on the result.

///<summary>

///Get Handler

///</summary>

///<param name=”get”></param>

///<returns></returns>

///<remarks>Get the state for the service</remarks> private IEnumerator<ITask> GetHandler(Get get)

{

yield return Arbiter.Choice( UpdateState(),

delegate(SuccessResult success)

{

get.ResponsePort.Post(_state);

},

delegate(Exception ex)

{

get.ResponsePort.Post(Fault.FromException(ex));

}

);

}

The GetHandler sets up a Choice that calls UpdateState, which returns a SuccessFailurePort. The

Choice arbiter listens for a message, which will be either a SuccessResult or an Exception. If a SuccessResult is returned, then the state is sent back on the ResponsePort. The state is global and is updated by UpdateState.

Because Get operations are intended to be accessible via the Web, the handler must return either the current state or a SOAP Fault. Therefore, if an exception occurs, the GetHandler has to convert it to a Fault before posting it back to the ResponsePort specified in the Get request. This can be done using

79

www.it-ebooks.info

Part I: Robotics Developer Studio Fundamentals

the FromException static method on the Fault class. Note that you need to include a using statement for W3C.Soap in order to use Fault.

The UpdateState method creates a new SuccessResultPort and then posts either a SuccessResult or an Exception to it based on the result of a Query command sent to the SSC-32 servo controller. In this case, the code has to convert from a SOAP Fault back to an Exception in order to return a failure status. Note that UpdateState actually returns a port with a message already sitting in it. This enables a

Choice to be used in the GetHandler.

// Synchronize the state by reading the joint positions from the controller private SuccessFailurePort UpdateState()

{

SuccessFailurePort resultPort = new SuccessFailurePort();

//Create new query pulse width command

int[] channels = new int[Lynx6ArmState.NUM_JOINTS] { 0, 1, 2, 3, 4, 5 }; ssc32.SSC32QueryPulseWidth queryCommand = new ssc32.SSC32QueryPulseWidth(); queryCommand.Channels = channels;

ssc32.SendSSC32Command command = new ssc32.SendSSC32Command(queryCommand); _ssc32Port.Post(command);

//Update the arm state based on the query response Activate(Arbiter.Choice(command.ResponsePort,

delegate(ssc32.SSC32ResponseType response)

{

ssc32.SSC32PulseWidthResponse queryResponse = (ssc32.SSC32PulseWidthResponse)response;

for (int i = 0; i < _state.Joints.Count; i++)

{

int jointAngle = ServoAngleToJointAngle(i, PulseWidthToAngle(queryResponse.PulseWidths[i]));

_state.Joints[i].State.Angular.DriveTargetOrientation = AngleToOrientationQuaternion(jointAngle);

// Remember the angle too - much easier to use! _state.Angles[i] = jointAngle;

}

_state.GripperAngle = (int)Math.Round(_state.Angles[(int)JointNumbers.Gripper]);

resultPort.Post(new SuccessResult());

},

delegate(Fault fault)

{

resultPort.Post(new Exception(fault.Reason[0].ToString()));

}

));

return resultPort;

}

80

www.it-ebooks.info

Chapter 2: Concurrency and Coordination Runtime (CCR)

Interoperation with Legacy Code

In terms of the CCR, Windows Forms (WinForms) constitute legacy code. WinForms use a STA model that does not work well under the CCR. Therefore, creating and using WinForms requires special treatment. See Chapter 3 for more information.

Using GDI graphics primitives suffers from problems similar to WinForms. This includes manipulating bitmaps. You need to be careful to ensure that you don’t end up with an access violation.

The Webcam service also needs to run in STA mode in order to use COM interop with older-style webcam drivers. For the STA model, you should create a dispatcher with a single thread.

The MTA (Multi-Threaded Apartment) model is a little different. If you want, or need, a fixed set of threads, then create a dispatcher with the appropriate number of threads. This will isolate these threads from the threads in the default DSS dispatcher.

If you have a requirement to use older code that uses the APM with Begin/End operations, such as asynchronous file I/O, then you can wrap these operations in classes that use CCR ports. For further information on this topic, search the discussion forum. There is also a good MSDN article called “Concurrent Affairs” by Jeffrey Richter on the MSDN Magazine website. It includes code for an APM wrapper. The URL is http://msdn.microsoft.com/msdnmag/issues/06/09/ConcurrentAffairs/ default.aspx.

Traps for New Players

Newcomers to MRDS often make a few common mistakes. This section briefly describes these and how to avoid them:

In conventional code — i.e., not in an iterator — if you forget to use Activate on a Receive, Choice, and so on, then nothing will happen. The code will compile, but it will not do what you expect.

If you call an iterator method directly, then nothing will happen. You must use SpawnIterator or some other method that activates it as a task. Again, the code will compile, but you will spend some time tearing your hair out wondering why it doesn’t do anything and breakpoints inside the method never fire.

Iterator syntax is incompatible with out and ref parameters, i.e., you cannot return anything. However, you can pass parameters into an iterator. The only workaround for this is to pass in a Port<type> and then post back an instance of type (which is some appropriate data type that you choose).

One way to call an iterator with a parameter is as follows:

yield return CcrHelpers.FromIteratorHandler(3,TestMethod);

81

www.it-ebooks.info

Part I: Robotics Developer Studio Fundamentals

where the CCR helper function is defined as follows:

static class CcrHelpers

{

public static ITask FromIteratorHandler(T0 t0, IterativeHandler handler)

{

yield return Arbiter.ExecuteToCompletion( base.TaskQueue,

new IterativeTask<T0>(t0, handler));

}

}

The SpawnIterator method has three overloads that take one, two, or three parameters and can be used as shown in the following example:

SpawnIterator<int, bool>(42, true, handler);

Arbiter.ExecuteToCompletion activates the task. However, you still need to use yield return or the code does not wait for completion. This is a little confusing.

Although this next tip really belongs in the next chapter, it is still relevant here. A service has one interleave, MainPortInterleavePort, which is created by DSS. If you set up other independent receivers, then they are not afforded the protection of the Exclusive Receiver Group and will run concurrently. This can result in very strange behavior because the state of the service might be updated simultaneously by two threads. The solution is to use the function

MainPortInterleave.CombineWith.

Similarly, when you use SpawnIterator or Activate, these tasks run in parallel with tasks from the main interleave.

Summary

The CCR is a very efficient and lightweight runtime. It allows multi-threaded programming without many of the complexities of a traditional approach. However, for many people it represents a different programming paradigm and it takes a little bit of getting used to. This chapter has introduced you to a variety of different methods in the CCR.

Although a lot of the CCR has been covered, many other APIs have not been discussed. In addition to reading the documentation, you can also use the Microsoft Robotics Developers Studio discussion forum as a resource. Use the Search function first. If you can’t find an answer to your question, then post a message. The forum is at http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=383&SiteID=1.

Chapter 3 discusses Decentralized Software Services (DSS). Using DSS is essential for writing MRDS services.

82