CS 452/652 Spring 2025 - Lecture 7

Producer/Consumer, Name Resolution, Measurements

May 27, 2025 prev next

SRR for Producer/Consumer

• communication pattern; asynchronous buffering; control blocking
• single producer, single consumer (SPSC)
  • producer sends, consumer responds with ack: "push" communication
  • consumer sends/requests, producer responds with element: "pull" communication
• multiple producers, single consumer (MPSC)
  • push communication works → consumer is server
  • pull communication: slow producer might block consumer (and thus other producers)
    • head-of-line blocking
• single producer, multiple consumers (SPMC)
  • push communication: head-of-line blocking
  • pull communication works → producer is server
• multiple producers, multiple consumers (MPMC)
  • need intermediary: buffer ("distributor", "warehouse")
  • buffer: acts as single consumer to producers, single producer to consumers
  • buffer receives requests, processes request, (delayed?) response
  • buffer full or empty: block respective producer(s)/consumer(s)?

Name Resolution

• resolve service names (chosen by application) to tids (chosen by the kernel)
  • implicit/default starting point: tid of name server
  • tid-based communication facilitated by kernel (see 'Communication' earlier)
• pervasive topic in computer science: mapping name spaces to each other
  • systems: memory address - name for circuit, name for device register
  • programming: variable - name for memory location or register
  • operating system: file - name for data on disk
  • Internet: DNS - name for IP address
  • Internet: URL - name for remote file/service and access protocol
• recursive problem
  • ask authority to resolve the mapping, but how to resolve the name of the authority
  • need a closure mechanism - something to ground the recursion
  • name resolution always starts in a default context with a default starting point!
    • file system: kernel using / (slash)
    • Internet domain names: local resolver using . (dot)

Name Server

• names: null-terminated character arrays
  • maximum length? error? truncate?
• WhoIs() for non-existing name? error? block?
• RegisterAs() with previous registration for same name?
• design of name server (data structure and operation):
  • how many names?
  • how often is name server used? when?
  • is this latency-critical?
• note that RegisterAs() and WhoIs() are not system calls

Measuring Execution Time

• duration of operation? basic approach:

      start = clock();
      operation();
      stop = clock();
  

• variability

  • time required for something() might vary each time you run it
    • interference?
  • do you want to:
    1. hide/smooth variability?
    2. measure and understand it?

• precision

  • how often does your clock tick?
  • are you trying to measure something that's faster than your clock ticks?

• overhead

  • clock() takes time
  • what you measure is actually the time for something() plus the time for clock()
  • significance depends on how fast operation() is, relative to clock()

• measure multiple times:

      loop N times:
          start = clock();
          operation();
          stop = clock();
      endloop;
  

  • helps with variability
    • compute variance, outliers, distribution
  • does not help with precision or overhead problem

• inflate impact of operation:

      start = clock();
      loop N times:
          operation();
      endloop;
      stop = clock();
  

  • precision - increase N until N * operation() is much slower than your clock
  • overhead - increase N until overhead is insignificant

• additional overheads

  • loop execution (counter, branch) - if relevant, measure with nop
  • concurrent workflow requires start/stop coordination
  • warm-up period with non-regular performance
  • sometimes: dummy side effects needed to keep optimizer from eliding experiment code
    → N must be large enough to mitigate impact of these overheads

• experiment duration

  • fixed N - simple
  • fixed run-time - predictable, but more difficult to set up and run

Realtime Loop

• real-time with fixed period X? naive approach:

      loop:
        action();
        sleep(X);
      endloop;
  

  ... is not sufficient:duration of action(), errors in sleep()

• account for deviations from perfect timing:

      target = clock();
      loop:
        action();
        target += X;
        sleep(target - clock());
      endloop;
  

Programming

• important principle: KISS
  • and: "premature optimization is root of all evil" (Donald Knuth)
• availability of resources: track < ARM < developer < PC
• think strategically about
  • functionality: start simple, add functionality in small steps
    • test (and commit) at each step
  • data structures: encapsulate, start simple, exchange later
  • bugs: not every bug is a show-stopper
• use unit testing where possible
• use assertions generously!
• ultimate goal is understanding everything!