<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>2026-07-23T00:25:37Z</responseDate>
  <request identifier="8970" metadataPrefix="oai_dc" verb="GetRecord">https://drops.dagstuhl.de/oai</request>
  <GetRecord>
    <record>
      <header>
        <identifier>oai:drops-oai.dagstuhl.de:8970</identifier>
        <datestamp>2024-03-12T12:02:07Z</datestamp>
        <setSpec>ddc:004</setSpec>
        <setSpec>open_access</setSpec>
      </header>
      <metadata>
        <oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
          <dc:title>Using Lock Servers to Scale Real-Time Locking Protocols: Chasing Ever-Increasing Core Counts (Artifact)</dc:title>
          <dc:creator>Nemitz, Catherine E.</dc:creator>
          <dc:creator>Amert, Tanya</dc:creator>
          <dc:creator>Anderson, James H.</dc:creator>
          <dc:subject>multiprocess locking protocols</dc:subject>
          <dc:subject>nested locks</dc:subject>
          <dc:subject>priority-inversion blocking</dc:subject>
          <dc:subject>reader/writer locks</dc:subject>
          <dc:subject>real-time locking protocols</dc:subject>
          <dc:description>During the past decade, parallelism-related issues have been at the forefront of real-time systems research due to the advent of multicore technologies.  In the coming years, such issues will loom ever larger due to increasing core counts.  Having more cores means a greater potential exists for platform capacity loss when the available parallelism cannot be fully exploited.  In this work, such capacity loss is considered in the context of real-time locking protocols.  In this context, lock nesting becomes a key concern as it can result in transitive blocking chains that force tasks to execute sequentially unnecessarily.  Such chains can be quite long on a larger machine.  Contention-sensitive real-time locking protocols have been proposed as a means of ``breaking'' transitive blocking chains, but such protocols tend to have high overhead due to more complicated lock/unlock logic.  To ease such overhead, the usage of lock servers is considered herein.  In particular, four specific lock-server paradigms are proposed and many nuances concerning their deployment are explored.  Experiments are presented that show that, by executing cache hot, lock servers can enable reductions in lock/unlock overhead of up to 86\%.  Such reductions make contention-sensitive protocols a viable approach in practice. This artifact contains the implementation of two contention-sensitive locking protocol variants implemented with four proposed lock-server paradigms, as well as the experiments with which they were evaluated.</dc:description>
          <dc:publisher>Schloss Dagstuhl – Leibniz-Zentrum für Informatik</dc:publisher>
          <dc:contributor>Catherine E. Nemitz and Tanya Amert and James H. Anderson</dc:contributor>
          <dc:date>2018</dc:date>
          <dc:relation>Is Part Of DARTS, Volume 4, Issue 2, Special Issue of the 30th Euromicro Conference on Real-Time Systems (ECRTS 2018)</dc:relation>
          <dc:type>Article</dc:type>
          <dc:type>Text</dc:type>
          <dc:type>doc-type:ResearchArticle</dc:type>
          <dc:type>publishedVersion</dc:type>
          <dc:format>application/pdf</dc:format>
          <dc:identifier>doi:10.4230/DARTS.4.2.2</dc:identifier>
          <dc:identifier>urn:nbn:de:0030-drops-89704</dc:identifier>
          <dc:identifier>https://drops.dagstuhl.de/entities/document/10.4230/DARTS.4.2.2</dc:identifier>
          <dc:language>eng</dc:language>
          <dc:rights>https://creativecommons.org/licenses/by/3.0/de/legalcode</dc:rights>
        </oai_dc:dc>
      </metadata>
    </record>
  </GetRecord>
</OAI-PMH>
