profile
viewpoint

sayedihashimi/slow-cheetah 243

XML Transforms for app.config and other XML files

jviau/durabletask-hosting 6

A Microsoft.Extensions.Hosting wrapper around the Microsoft.Azure.DurableTask framework.

afontaine/ECE421 1

For ECE421

jviau/vio-dotnet-extensions 1

Extensions for the dotnet cli

davilimap/slow-cheetah 0

XML Transforms for app.config and other XML files

jviau/azure-devtestlab 0

Azure DevTestLab artifacts, scripts and samples

jviau/azure-rest-api-specs 0

The source for REST API specifications for Microsoft Azure.

jviau/azure-sdk-for-net 0

.NET Libraries for Azure

jviau/durabletask 0

Durable Task Framework allows users to write long running persistent workflows in C# using the async/await capabilities.

push eventmicrosoft/vs-threading

dependabot[bot]

commit sha abd4e96649f3bb6112ea7e17504d0efdd09fa2b6

Bump Microsoft.Diagnostics.Runtime from 2.0.151903 to 2.0.156101 (#721) Bumps [Microsoft.Diagnostics.Runtime](https://github.com/Microsoft/clrmd) from 2.0.151903 to 2.0.156101. - [Release notes](https://github.com/Microsoft/clrmd/releases) - [Changelog](https://github.com/microsoft/clrmd/blob/master/doc/ReleaseNotes2.0.md) - [Commits](https://github.com/Microsoft/clrmd/commits) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

push time in 5 days

delete branch microsoft/vs-threading

delete branch : dependabot/nuget/Microsoft.Diagnostics.Runtime-2.0.156101

delete time in 5 days

PR merged microsoft/vs-threading

Bump Microsoft.Diagnostics.Runtime from 2.0.151903 to 2.0.156101 dependencies

Bumps Microsoft.Diagnostics.Runtime from 2.0.151903 to 2.0.156101. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/Microsoft/clrmd/commits">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in 5 days

PR opened microsoft/vs-threading

Bump Microsoft.Diagnostics.Runtime from 2.0.151903 to 2.0.156101

Bumps Microsoft.Diagnostics.Runtime from 2.0.151903 to 2.0.156101. <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/Microsoft/clrmd/commits">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

</details>

+1 -1

0 comment

1 changed file

pr created time in 6 days

push eventmicrosoft/vs-threading

Lifeng Lu

commit sha 94fae4eefd13d35801851fab1525ce2744ff2882

Add a new unit test to reproduce the dead lock caused by a write lock request.

view details

Lifeng Lu

commit sha 8893d9f9908d6e5b84edb1640ec1bc75b01debd6

Initial dead lock fix.

view details

Lifeng Lu

commit sha 4be4690a2c9031ae5d978e8681215115f59092d4

Merge remote-tracking branch 'origin/master' into dev/lifengl/writeLockRequestHang

view details

Lifeng Lu

commit sha 921b1a033b4e85c3a370ce2bf446da2e49567aa7

Fix build warnings.

view details

Lifeng Lu

commit sha 95234d07b99c325c07aa0ec931327ae574e14ae4

Fix problems raised in the code review.

view details

Lifeng Lu

commit sha 7ba862d1974ecd055e4ead5f8d2df36798ca239c

Add more unit tests.

view details

Lifeng Lu

commit sha f226d686e4e38f171d109065f03aaa4f1a4f0d7c

Fix assertion in a wrong location in the unit test.

view details

Lifeng Lu

commit sha 4752ef9bbfc2914d955c18b8db4ce9c3c798693d

Use better methods to create TimeSpan.

view details

Lifeng Lu

commit sha 654ee33702024fa48165fd5c963784faa4492cd4

Update some spelling.

view details

Lifeng Lu

commit sha f08f7aecc56e79011cfa772fa1242d8054aea00d

Merge pull request #715 from microsoft/dev/lifengl/writeLockRequestHang Mitigate deadlock between AsyncReaderWriterLock and main thread

view details

push time in 7 days

delete branch microsoft/vs-threading

delete branch : dev/lifengl/writeLockRequestHang

delete time in 7 days

PR merged microsoft/vs-threading

Mitigate deadlock between AsyncReaderWriterLock and main thread

This is a PR to fix #710.

The change basically follows what has been discussed in the thread of the issue. Unit tests have been added to the PR.

It doesn't change behavior for existing consumers. It must be updated to pass in a JTF context in the constructor to enable the logic to handle this type of deadlocks.

+462 -4

3 comments

7 changed files

lifengl

pr closed time in 7 days

issue closedmicrosoft/vs-threading

AsyncReaderWriterResourceLock tries to exhaust read locks to unblock write lock requests leads to deadlocks

Dead lock can be formed through this pattern:

1, Task A gets a read lock 2, Task B tries to get a write lock 3, Task C starts, tries to get a read lock. This request is blocked due to the pending write lock request 4, Task A waits Task C to finish for other reasons. Inside VS, the reason is often to join a common/shared computation

Now, the system runs into a dead lock state, B cannot get the write lock, because A is waiting C. Various team members run into this dead lock when using the product. It is a general pattern and happens in various different functions of the product, so hard to measure. (DevDiv-1090831)

closed time in 7 days

lifengl

Pull request review commentmicrosoft/vs-threading

Mitigate deadlock between AsyncReaderWriterLock and main thread

 protected bool CaptureDiagnostics             set { this.captureDiagnostics = value; }         } +        /// <summary>+        /// Gets a time delay to check whether pending writer lock and reader locks forms a deadlock.+        /// </summary>+        protected virtual TimeSpan DeadlockCheckTimeOut => DefaultDeadlockCheckTimeOut;

fixed

lifengl

comment created time in 8 days

push eventmicrosoft/vs-threading

Lifeng Lu

commit sha 654ee33702024fa48165fd5c963784faa4492cd4

Update some spelling.

view details

push time in 8 days

Pull request review commentmicrosoft/vs-threading

Mitigate deadlock between AsyncReaderWriterLock and main thread

 protected bool CaptureDiagnostics             set { this.captureDiagnostics = value; }         } +        /// <summary>+        /// Gets a time delay to check whether pending writer lock and reader locks forms a deadlock.+        /// </summary>+        protected virtual TimeSpan DeadlockCheckTimeOut => DefaultDeadlockCheckTimeOut;

Timeout is also a discrete term. It's conventional to not capitalize the O.

lifengl

comment created time in 8 days

pull request commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

Hey, @AArnott : I updated the code based on the latest comments & the earlier comments of this PR. I think I finish the work, and it is ready to be reviewed & merged, when you and any other reviewer are ok with it.

lifengl

comment created time in 8 days

push eventmicrosoft/vs-threading

Lifeng Lu

commit sha 4752ef9bbfc2914d955c18b8db4ce9c3c798693d

Use better methods to create TimeSpan.

view details

push time in 8 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 namespace Microsoft.VisualStudio.Threading     public partial class AsyncReaderWriterLock : IDisposable     {         /// <summary>-        /// A time delay to check whether pending writer lock and reader locks forms a dead lock.+        /// A time delay to check whether pending writer lock and reader locks forms a deadlock.         /// </summary>-        private const int DefaultDeadLockCheckTimeOutInMilliseconds = 3 * 1000;+        private static readonly TimeSpan DefaultDeadlockCheckTimeOut = new TimeSpan(hours: 0, minutes: 0, seconds: 3);

Yeah, that is right :).

lifengl

comment created time in 8 days

startedkylecjo/whats-for-dinner

started time in 9 days

startedNoteable-DubHacks2020/Noteable

started time in 9 days

startedCityofEdmonton/AI-Pothole-Detection-Using-YOLO

started time in 9 days

pull request commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

@lifengl I see this PR is not a 'draft' any more but your PR description still describes it as a draft. Are you looking for a review from me at this point, or are you still developing this?

lifengl

comment created time in 9 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 namespace Microsoft.VisualStudio.Threading     public partial class AsyncReaderWriterLock : IDisposable     {         /// <summary>-        /// A time delay to check whether pending writer lock and reader locks forms a dead lock.+        /// A time delay to check whether pending writer lock and reader locks forms a deadlock.         /// </summary>-        private const int DefaultDeadLockCheckTimeOutInMilliseconds = 3 * 1000;+        private static readonly TimeSpan DefaultDeadlockCheckTimeOut = new TimeSpan(hours: 0, minutes: 0, seconds: 3);

tip: I find TimeSpan.FromSeconds(3) to be a succinct way of expressing this.

lifengl

comment created time in 9 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 public ReaderWriterLockWithFastDeadLockCheck(JoinableTaskContext joinableTaskCon         {         } -        protected override int DeadLockCheckTimeOutInMilliseconds => 50;+        protected override TimeSpan DeadlockCheckTimeOut { get; } = new TimeSpan(days: 0, hours: 0, minutes: 0, seconds: 0, milliseconds: 50);

tip: TimeSpan.FromMilliseconds(50) seems like a good fit here.

lifengl

comment created time in 9 days

push eventmicrosoft/vs-threading

Lifeng Lu

commit sha f226d686e4e38f171d109065f03aaa4f1a4f0d7c

Fix assertion in a wrong location in the unit test.

view details

push time in 9 days

push eventmicrosoft/vs-threading

Lifeng Lu

commit sha 95234d07b99c325c07aa0ec931327ae574e14ae4

Fix problems raised in the code review.

view details

Lifeng Lu

commit sha 7ba862d1974ecd055e4ead5f8d2df36798ca239c

Add more unit tests.

view details

push time in 10 days

issue commentmicrosoft/slow-cheetah

Ability to transform all configuration

This is not included in SlowCheetah's main functionality, but can be achieved through MSBuild targets. See the docs for information on how the SlowCheetah targets work (also here for more info on targets). It seems like you can just add your files to the list of files that are transformed, ScFilesToTransform.

Hi @davilimap , can we expect this as a new feature in next version?

TPGEric

comment created time in 10 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 private void PendAwaiter(Awaiter awaiter)                 {                     Queue<Awaiter>? queue = this.GetLockQueue(awaiter.Kind);                     queue.Enqueue(awaiter);++                    if (awaiter.Kind == LockKind.Write)+                    {+                        this.EnablePendingWriterLockDeadLockWatching();+                    }                 }             }         } +        private void EnablePendingWriterLockDeadLockWatching()

yeah, i made that change.

lifengl

comment created time in 10 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 private void PendAwaiter(Awaiter awaiter)                 {                     Queue<Awaiter>? queue = this.GetLockQueue(awaiter.Kind);                     queue.Enqueue(awaiter);++                    if (awaiter.Kind == LockKind.Write)+                    {+                        this.EnablePendingWriterLockDeadLockWatching();+                    }                 }             }         } +        private void EnablePendingWriterLockDeadLockWatching()+        {+            if (this.joinableTaskContext != null &&+                this.pendingWriterLockDeadLockCheckTimer == null &&+                this.waitingWriters.Count > 0 &&+                (this.issuedReadLocks.Count > 0 || this.issuedUpgradeableReadLocks.Count > 0))+            {+                this.pendingWriterLockDeadLockCheckTimer = new Timer(PendingWriterLockDeadLockWatchingCallback, this, this.DeadLockCheckTimeOutInMilliseconds, -1);+            }+        }++        private void StopPendingWriterLockDeadLockWatching()+        {+            if (this.pendingWriterLockDeadLockCheckTimer != null && this.waitingWriters.Count == 0)

We actually checked it before calling the function. Yes, it makes sense to remove that part of check in this function.

lifengl

comment created time in 10 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 private static bool HasAnyNestedLocks(Awaiter lck, HashSet<Awaiter> lockCollecti             return false;         } +        private static void PendingWriterLockDeadLockWatchingCallback(object? state)+        {+            var readerWriterLock = state as AsyncReaderWriterLock;+            if (readerWriterLock != null)

yeah, you are right. That is better.

lifengl

comment created time in 10 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 public void Dispose()         /// <param name="disposing"><c>true</c> if <see cref="Dispose()"/> was called; <c>false</c> if the object is being finalized.</param>         protected virtual void Dispose(bool disposing)         {+            if (disposing)+            {+                lock (this.syncObject)+                {+                    this.pendingWriterLockDeadLockCheckTimer?.Dispose();

makes sense.

lifengl

comment created time in 10 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 namespace Microsoft.VisualStudio.Threading     /// </devnotes>     public partial class AsyncReaderWriterLock : IDisposable     {+        /// <summary>+        /// A time delay to check whether pending writer lock and reader locks forms a dead lock.

thanks, i fixed them, and will scan CPS code too.

lifengl

comment created time in 10 days

Pull request review commentmicrosoft/vs-threading

Dev/lifengl/write lock request hang

 internal static void OnTaskCompleted(IJoinableTaskDependent taskItem)             taskItem.GetJoinableTaskDependentData().OnTaskCompleted();         } +        /// <summary>+        /// Get all tasks inside the cadidate sets tasks, which are depended by one or more task in the source tasks list.+        /// </summary>+        /// <param name="sourceTasks">A collection of JoinableTasks represents source tasks.</param>+        /// <param name="candidateTasks">A collection of JoinableTasks which represents cadidates.</param>+        /// <returns>A set of tasks matching the condition.</returns>+        internal static HashSet<JoinableTask> GetDependentTasksFromCandidates(IEnumerable<JoinableTask> sourceTasks, IEnumerable<JoinableTask> candidateTasks)+        {+            Requires.NotNull(sourceTasks, nameof(sourceTasks));+            Requires.NotNull(candidateTasks, nameof(candidateTasks));++            var candidates = new HashSet<JoinableTask>(candidateTasks);+            if (candidates.Count == 0)+            {+                return candidates;+            }++            var results = new HashSet<JoinableTask>();+            var visited = new HashSet<IJoinableTaskDependent>();++            var queue = new Queue<IJoinableTaskDependent>();+            foreach (JoinableTask? task in sourceTasks)+            {+                if (task != null && visited.Add(task))

no, i tried to follow the pattern, because many 'foreach' code in the JoinableTask checked element, even the element in the collection type is not nullable. I will remove the nullable from the line 191, and leave the null check on line 193, just to make it safe.

lifengl

comment created time in 10 days

more