ConfigureAwait behavior in C Sharp (C#) - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to await the task without capturing the current synchronization context.

C Sharp (C#)

await someTask.[1](false);

Drag options to blanks, or click blank then click option'

AWait

BConfigureAwait

CGetAwaiter

DContinueWith

Attempts:

3 left

💡 Hint

Common Mistakes

Using ContinueWith instead of ConfigureAwait.

Forgetting to call ConfigureAwait at all.

Using GetAwaiter which does not take parameters.

The ConfigureAwait(false) method tells the awaiter not to capture the current synchronization context.

2fill in blank

medium

Complete the code to resume on the original synchronization context after awaiting.

C Sharp (C#)

await someTask.[1](true);

Drag options to blanks, or click blank then click option'

AGetAwaiter

BContinueWith

CConfigureAwait

DWait

Attempts:

3 left

💡 Hint

Common Mistakes

Passing false when the goal is to resume on the original context.

Using ContinueWith which does not guarantee context capture.

Using ConfigureAwait(true) ensures the continuation runs on the original context, which is the default behavior.

3fill in blank

hard

Complete the code to await the task without capturing the current synchronization context.

C Sharp (C#)

var result = await someTask.[1];

Drag options to blanks, or click blank then click option'

AConfigureAwait

BConfigureAwait(true)

CGetAwaiter().GetResult()

DConfigureAwait(false)

Attempts:

3 left

💡 Hint

Common Mistakes

Using just ConfigureAwait without the parameter.

Using ConfigureAwait(true) which captures the context.

Using blocking calls like GetAwaiter().GetResult() which can deadlock.

ConfigureAwait(false) avoids capturing the synchronization context. This full expression is needed here.

4fill in blank

hard

Fill both blanks to create a task that does not capture the synchronization context and returns a string result.

C Sharp (C#)

async Task<string> GetDataAsync() {
    var data = await FetchDataAsync().[1]([2]);
    return data;
}

Drag options to blanks, or click blank then click option'

AConfigureAwait

Bfalse

Ctrue

DGetAwaiter

Attempts:

3 left

💡 Hint

Common Mistakes

Passing true instead of false.

Using GetAwaiter which does not take parameters.

Using ConfigureAwait(false) avoids capturing the synchronization context, which can improve performance in some scenarios.

5fill in blank

hard

Fill both blanks to create a dictionary comprehension that stores task results without capturing the synchronization context.

C Sharp (C#)

var results = new Dictionary<int, string>();
foreach (var id in ids) {
    results[id] = await GetDataAsync(id).[1]([2]);
}

Drag options to blanks, or click blank then click option'

AConfigureAwait

Bfalse

DConfigureAwait(false)

Attempts:

3 left

💡 Hint

Common Mistakes

Putting ConfigureAwait(false) as one option (not allowed here).

Adding extra characters in the third blank.

The correct syntax is await GetDataAsync(id).ConfigureAwait(false); The third blank is empty because the semicolon is already in the code.

Practice

1.

What does ConfigureAwait(false) do in an async method?

easy

A. It cancels the async operation immediately.

B. It forces the continuation to run on the UI thread.

C. It tells the continuation not to resume on the original synchronization context.

D. It delays the continuation by a fixed time.

Solution

1. Step 1: Understand ConfigureAwait parameter

   ConfigureAwait(false) means the continuation after await does not have to run on the original context (like UI thread).

2. Step 2: Effect on continuation context

   This improves performance and avoids deadlocks by not forcing the continuation to resume on the original synchronization context.

3. Final Answer:

   It tells the continuation not to resume on the original synchronization context. -> Option C

4. Quick Check:

   ConfigureAwait(false) = no original context resume [OK]

Hint: False means no original context resume, true means resume original [OK]

Common Mistakes:

• Thinking ConfigureAwait(false) forces UI thread continuation
• Confusing ConfigureAwait with cancellation
• Assuming it delays the continuation

2.

Which of the following is the correct syntax to avoid resuming on the original context after an await?

await SomeAsyncMethod()...

easy

A. await SomeAsyncMethod().ConfigureAwait(true);

B. await SomeAsyncMethod().ConfigureAwait(null);

C. await SomeAsyncMethod().ConfigureAwait();

D. await SomeAsyncMethod().ConfigureAwait(false);

Solution

1. Step 1: Recall ConfigureAwait syntax

   The method ConfigureAwait takes a boolean parameter: true or false.

2. Step 2: Identify correct parameter to avoid original context

   Using false tells the continuation not to resume on the original context.

3. Final Answer:

   await SomeAsyncMethod().ConfigureAwait(false); -> Option D

4. Quick Check:

   ConfigureAwait(false) disables original context resume [OK]

Hint: Use false to avoid original context, true to keep it [OK]

Common Mistakes:

• Using ConfigureAwait(true) to avoid context (it keeps it)
• Calling ConfigureAwait without parameter (invalid)
• Passing null to ConfigureAwait (invalid)

3.

Consider the following code snippet:

async Task Example()
{
    Console.WriteLine($"Start on thread {Thread.CurrentThread.ManagedThreadId}");
    await Task.Delay(100).ConfigureAwait(false);
    Console.WriteLine($"After await on thread {Thread.CurrentThread.ManagedThreadId}");
}

What is the likely output behavior regarding thread IDs?

medium

A. Both lines print the same thread ID.

B. The second line prints a different thread ID than the first.

C. The code will cause a deadlock.

D. The code will not compile.

Solution

1. Step 1: Analyze ConfigureAwait(false) effect on thread

   Using ConfigureAwait(false) means the continuation after await can run on any thread, not necessarily the original one.

2. Step 2: Compare thread IDs before and after await

   The first Console.WriteLine runs on the original thread. After await, the continuation may run on a different thread, so thread IDs can differ.

3. Final Answer:

   The second line prints a different thread ID than the first. -> Option B

4. Quick Check:

   ConfigureAwait(false) continuation thread may differ [OK]

Hint: False allows continuation on any thread, so thread ID can change [OK]

Common Mistakes:

• Assuming thread ID stays the same after ConfigureAwait(false)
• Expecting deadlock from this code
• Thinking code won't compile due to ConfigureAwait

4.

Identify the problem in this code snippet:

public async Task LoadDataAsync()
{
    var data = await GetDataAsync().ConfigureAwait(true);
    UpdateUI(data);
}

void UpdateUI(string data)
{
    // Update UI elements here
}

What issue might occur and how to fix it?

medium

A. Deadlock if called from UI thread; fix by using ConfigureAwait(false).

B. Compilation error due to ConfigureAwait(true); fix by removing it.

C. UpdateUI runs on background thread; fix by using ConfigureAwait(true).

D. No issue; code is correct as is.

Solution

1. Step 1: Understand ConfigureAwait(true) behavior

   ConfigureAwait(true) resumes on the original context, usually the UI thread.

2. Step 2: Identify deadlock risk

   If LoadDataAsync is called synchronously from UI thread waiting on the task, it can cause deadlock because continuation waits for UI thread to be free.

3. Step 3: Fix by avoiding original context resume

   Using ConfigureAwait(false) avoids resuming on UI thread, preventing deadlock.

4. Final Answer:

   Deadlock if called from UI thread; fix by using ConfigureAwait(false). -> Option A

5. Quick Check:

   ConfigureAwait(true) can cause deadlock; false avoids it [OK]

Hint: Use ConfigureAwait(false) to prevent UI thread deadlocks [OK]

Common Mistakes:

• Thinking ConfigureAwait(true) causes compilation error
• Assuming UpdateUI runs on background thread with ConfigureAwait(true)
• Ignoring deadlock risk when awaiting on UI thread

5.

You have a library method async Task<string> FetchDataAsync() that uses ConfigureAwait(false). You want to call it from a UI app and update UI controls after awaiting. How should you write your calling code to safely update the UI?

hard

A. await FetchDataAsync(); then update UI directly, no extra steps needed.

B. await FetchDataAsync().ConfigureAwait(false); then marshal back to UI thread before updating UI.

C. await FetchDataAsync().ConfigureAwait(false); then update UI directly.

D. Call FetchDataAsync synchronously with .Result to avoid context issues.

Solution

1. Step 1: Understand library ConfigureAwait(false)

   Library uses ConfigureAwait(false) internally, avoiding context capture inside library method.

2. Step 2: Caller await behavior

   await FetchDataAsync() defaults to ConfigureAwait(true), resuming continuation on original UI context.

3. Step 3: UI update safety

   Continuation runs on UI thread, safe to update UI controls directly after await.

4. Final Answer:

   await FetchDataAsync(); then update UI directly, no extra steps needed. -> Option A

5. Quick Check:

   Library(false) + default await(true) = UI thread resume [OK]

Hint: Library(false) + UI default await = safe UI update [OK]

Common Mistakes:

• Unnecessarily using ConfigureAwait(false) in UI code requiring marshal
• Calling library method synchronously with .Result
• Assuming library(false) prevents caller UI context capture