Project

General

Profile

Feature #15374

Milestone #15372: art multi-threading phase 1

Modifying all framework-provided services to be thread safe.

Added by Marc Paterno over 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
02/24/2017
Due date:
% Done:

100%

Estimated time:
(Total: 116.00 h)
Spent time:
4.00 h (Total: 139.00 h)
Scope:
Internal
Experiment:
-
SSI Package:
Duration:

Description

This includes determining any restrictions on user code interacting with the framework services.


Subtasks

Feature #15655: Allow ServiceHandle<T const> constructionsClosedKyle Knoepfel

Feature #15656: Make RandomNumberGenerator service thread safeClosedKyle Knoepfel

Feature #15657: Make MemoryTracker service thread safeClosedKyle Knoepfel

Feature #15658: Make TimeTracker service thread safeClosedKyle Knoepfel

Feature #15659: Make FileCatalogMetadata thread safeClosedKyle Knoepfel

Feature #15660: Make FloatingPointControl thread safeClosedKyle Knoepfel

Feature #15661: Make TriggerNamesService thread safeClosedKyle Knoepfel

Feature #15663: Restrict access to ServiceRegistry instanceClosedKyle Knoepfel

cetlib - Feature #15672: Make SQLite cet::Ntuple facility thread safeClosedKyle Knoepfel

Feature #15843: Create DatabaseConnection serviceClosedKyle Knoepfel

History

#1 Updated by Kyle Knoepfel over 2 years ago

  • Status changed from New to Accepted

#2 Updated by Kyle Knoepfel over 2 years ago

  • Assignee set to Christopher Green

#3 Updated by Christopher Green over 2 years ago

  • Assignee changed from Christopher Green to Paul Russo

#4 Updated by Kyle Knoepfel over 2 years ago

  • Status changed from Accepted to Assigned

#5 Updated by Kyle Knoepfel over 2 years ago

  • Assignee changed from Paul Russo to Kyle Knoepfel

This request is interpreted to refer to modifying framework-provided services primarily so that the interface exposed by ServiceHandle<T> is thread-safe for the supplied template argument T. Modifications to the callback system (as supported through the ActivityRegistry), and its use in the art-provided services, will primarily be part of introducing the context system (issue #15384). In some cases, it may be necessary to address both aspects at once.

This task involves several facets, discussed below.

Minor changes to the service system

There are changes that can be made to the service system itself that can facilitate safer interactions with the registry, either directly or indirectly through ServiceHandle<T>. Two of those include:

  • Providing the ability for users to call ServiceHandle<T const>, where the returned object provides const-only access to the service. In other words, only the const-qualified interface can be used. Providing such a facility enables a clear interpretation of const thread-safety, where calls to const-qualified functions are guaranteed to be thread-safe as long as no data members are explicitly or implicitly changed during the call (#15655).
  • Restricting access to the ServiceRegistry so that users cannot directly interact with its instance (#15663).

Changes to the services themselves

The services are constructed at process start up, which occurs in a single-threaded environment. The service constructors, therefore, do no need to accommodate multi-threading.

During the milestone effort estimation process, the following services were deemed to need adjustment:

The services below were deemed to need no adjustment:

  • SimpleInteraction: Not to be used in multi-threaded mode. If nobody is using it, get rid of it or make it be a test service.
  • TFileService: Following CMSSW, this would be a "shared resource", which implies serial access and thus no changes required.
  • ScheduleContext: This will be replaced by the context system.
  • CurrentModule: This will be replaced by the context system.
  • MemoryAdjuster: Has no header and is already thread-safe.
  • Tracer: Has no header, but will need to be adjusted to accommodate multi-threading in its callbacks.
  • TrivialFileDelivery
  • TrivialFileTransfer

#6 Updated by Kyle Knoepfel over 2 years ago

A discussion will be necessary with the artdaq team regarding their usage of UserInteraction, SimpleInteraction, and the PathSelection services. If alternative approaches can be used, then moving the services to being test services may be desirable.

#7 Updated by Kyle Knoepfel over 2 years ago

The PathSelection, UserInteraction, and SimpleInteraction services have been removed, along with all art-job reconfiguration internals. The ED{Producer,Filter,Analyzer}::reconfigure virtual functions have been retained, although they are no longer called by the framework.

#8 Updated by Kyle Knoepfel over 2 years ago

  • Status changed from Assigned to Resolved

#9 Updated by Kyle Knoepfel over 2 years ago

  • Target version set to 1209

#10 Updated by Kyle Knoepfel about 2 years ago

  • Target version changed from 1209 to 2.07.01

#11 Updated by Kyle Knoepfel about 2 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF