Discussion 10 handout

Group members (names & NetIDs)

Objectives

• Identify potential for and consequences of race conditions.
• Implement a concurrency abstraction using a mutex and condition variable.

Orientation

Download the dis10 project code and open it as a project in IntelliJ as you would an assignment. Read BarrierDemo, then run it. Is the requirement regarding subtask B being respected?

Unsynchronized attempt

Attempt to implement Barrier::await() without using synchronization (e.g. by “spinning”—checking for a condition in a loop to wait until it becomes true). Ignore postAction for now.

Run BarrierDemo again. What behavior do you see? (different groups may see different behavior)

Synchronization

Where is synchronization needed?

Synchronization is not required everywhere, even when a class is shared between threads. It is important to recognize in which situations synchronization is required, so you can confidently avoid race conditions without unnecessary overhead.

Is synchronization required in the constructor? If so, which object should be synchronized on? If not, justify why not.

Is synchronization required in totalThreads()? If so, which object should be synchronized on? If not, justify why not.

Is synchronization required in awaitingThreads()? If so, which object should be synchronized on? If not, justify why not.

Await

Fix your implementation of await() so that it uses synchronization to avoid race conditions and to block without “spinning”. Continue ignoring postAction for now.

Run BarrierDemo again. Is the requirement regarding subtask B being respected?

postAction

Implement the requirement related to postAction. Run BarrierDemo again. Is the behavior what you would expect?

Reference the state diagram from lecture 20. Which state is each thread in when postAction is executed? Use the portion numbers from your most recent run.

Going further

What would happen if more than totalThreads called await() on a Barrier?

Submission

1. Open the assignment page for “Discussion activity 10” in CMSX
2. [Recorder] Find the “Group Management” section and invite each group member
3. [Others] Refresh the page and accept your invitation
4. [Recorder] Take a picture of your work and save as either a JPEG or a PDF file named “discussion_responses”. After all invitations have been accepted, upload your picture along with your code as your group’s submission.
   • Recommended scanning apps: Microsoft Office Lens, Adobe Scan, Genius Scan, Evernote Scannable

Ensure that your group is formed and your work submitted before the Friday evening deadline.

Tips and reminders

• Discussion is not a race. Focus on the current activity being facilitated by your TA and engage your whole group to propose and explain ideas.
• Elect a recorder to maintain the “master” copy of your work (others are still encouraged to jot down ideas on scratch paper). Rotate this position each week.
• It is a violation of academic integrity to credit someone for work if they were not present when the work was done, and the whole group is accountable. Your CMS group must only include classmates who attended section with you on that day. Remember that our participation policies accommodate occasional absences without penalty.
• It is your individual responsibility to ensure that you are grouped on CMS and that your group’s work is submitted before the deadline. Log into CMS the day after section to ensure that everything is in order, and contact your groupmates if not. It would be prudent for multiple members to photograph the group’s work.
• Only one group member (typically the recorder) needs to upload a submission. But their submission must not be uploaded until after all group members have confirmed their membership in CMS (contact your TA if you have trouble grouping in CMS).