Project

General

Profile

Idea #15350

art as separate process in EventBuilder and DataLogger

Added by Eric Flumerfelt over 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
Under Consideration
Target version:
Start date:
01/27/2017
Due date:
% Done:

0%

Estimated time:
Experiment:
-
Duration:

Description

This afternoon, Ron and I had a discussion with Marc Paterno about the coming changes to art and how they might affect artdaq. We came up with a scheme by which artdaq will be pretty much completely insulated from changes to art, while also giving us the coveted ability to reconfigure art. This solution does incur one additional memcpy operation.

The DataReceiverManager currently starts a thread for each configured TransferPlugin, which allocates a temporary Fragment that the TransferPlugin::receiveFragment method copies the fragment from the receive buffer to this temporary fragment, whose unique_ptr is then passed through the system to the art thread. The proposed solution is that the temporary fragment becomes a region of shared memory managed by another class (which will look a lot like Shmem_transfer, possibly to the point of sharing code), and a new art input source which copies out of this shared memory and informs the manager that the buffer can be reused. (RawInput currently is responsible for freeing the temporary fragment created in DataReceiverManager, by letting the unique_ptr go out of scope.)

An advantage of this system is that artdaq becomes completely separate from art, so if user code crashes, we can handle it gracefully and we can also start multiple art processes from one artdaq process.
This will also aid in debugging, as we should be able to run without an art thread at all, or run the art thread by itself with an appropriate shared memory driver application.

unnamed-1.jpg (87.7 KB) unnamed-1.jpg John Freeman, 04/24/2017 01:48 PM

Related issues

Related to artdaq - Idea #14781: Investigate starting art as a subordinate, but separate, process in the EventBuilder and AggregatorClosed12/07/2016

History

#1 Updated by Eric Flumerfelt over 3 years ago

  • Related to Idea #14781: Investigate starting art as a subordinate, but separate, process in the EventBuilder and Aggregator added

#2 Updated by John Freeman over 3 years ago

Eric and I discussed where the design for the separate-art-threads model stands. A picture of a drawing Eric made is shown above, describing the basic outline of how to get events from an eventbuilder to a separate art thread.

In a nutshell, a region of shared memory will take over much of the functionality of the EventStore. Right now, the EventStore receives fragments, assembles them into RawEvents, and then puts the RawEvents onto the global event queue from which the RawInput source extracts them and sends them to the art workflow embedded within the eventbuilder. With this proposed change, the eventbuilder will stick fragments into shared memory, and mark when enough fragments from the same event have been put in the shared memory to constitute a complete event. Once there's a complete event, a new art input source running in a standalone art process can extract the event out of the shared memory. Potential race conditions in this model will of course need to be handled in the code.

Two comments:

-Wes has already done some work on a circular memory buffer which may be applicable here

-Will we even need an EventStore anymore once this is implemented, or would it be more elegant to move its remaining functionality into other parts of the code?

#3 Updated by Eric Flumerfelt over 2 years ago

  • Status changed from New to Closed
  • Assignee set to Eric Flumerfelt
  • Target version set to artdaq v3_00_01


Also available in: Atom PDF