Skip to content

Use System.Threading.Lock where applicable#288

Merged
slozier merged 5 commits intoIronLanguages:mainfrom
BCSharp:fast_lock
Feb 21, 2026
Merged

Use System.Threading.Lock where applicable#288
slozier merged 5 commits intoIronLanguages:mainfrom
BCSharp:fast_lock

Conversation

@BCSharp
Copy link
Copy Markdown
Member

@BCSharp BCSharp commented Feb 20, 2026

Performance improvement: System.Threading.Lock provides a more efficient locking primitive in .NET 9.0+ than locking on a generic object.

Copy link
Copy Markdown
Contributor

@slozier slozier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me.

I was trying to see if there was a "cleaner" pattern, but only think I came up with was putting an alias at the top:

#if !NET9_0_OR_GREATER
using Lock = System.Object;
#endif

@BCSharp
Copy link
Copy Markdown
Member Author

BCSharp commented Feb 20, 2026

Thanks for the review. I want to do the same in IronPython so let's agree here on the pattern, so it matches across the projects.

@BCSharp BCSharp changed the title Add System.Threading.Lock where applicable Use System.Threading.Lock where applicable Feb 21, 2026
@slozier
Copy link
Copy Markdown
Contributor

slozier commented Feb 21, 2026

Interesting. Not sure how I feel about global usings, they seem a bit too magical. 😄 But I'm willing to give it a try... I can see how having if conditions would become noisy with the amount of locks used in IronPython.

Alternate in between solution to make it a little less magical could be do drop the global using on .NET 9+ and require using System.Threading for each file that uses it? Just a thought, don't have a strong opinion about it.

@BCSharp
Copy link
Copy Markdown
Member Author

BCSharp commented Feb 21, 2026

Not sure how I feel about global usings, they seem a bit too magical. 😄 But I'm willing to give it a try...

Well, I do have an opinion on them and my personal preferences. Generally, I am rather conservative:

  1. I strongly dislike implicit usings, except for single-file programs.
  2. I prefer file-scope usings, but allow for global usings for very limited and justified cases that significantly cut down the ceremony. That usually means types that are not specific to any code area and/or are widely used (rather than whole namespaces), or standard boilerplate XAML namespaces.
  3. I dislike global usings defined in .csproj or .props files. Global usings are already somewhat — as you say — “magical”, and having them buried inside XML files just feels too obscure. So I like a dedicated .cs file for global usings only, even though it means one extra file at the top level.

In this practical case it means that Lock is qualified to be introduced as a global using alias, since it serves a specific but universal purpose across the code base. However, I'd rather have it defined in a dedicated .cs file, not directly in Directory.Build.props. I put it here inside .props only because IronPython already defines a global usings alias in its Directory.Build.props (NotNoneAttribute) and I tried to be consistent, but that was not my preference.

Alternate in between solution to make it a little less magical could be do drop the global using on .NET 9+ and require using System.Threading for each file that uses it? Just a thought, don't have a strong opinion about it.

I'm not sure I understand how this would work without #ifs polluting the code, since Lock should be Object for pre-.NET 9 targets.

Anyway, I am going to commit my preferred form now, counting on your willing to give it a try. I'll let you merge the PR is you are OK with it, otherwise looking forward to your opinion.

@slozier
Copy link
Copy Markdown
Contributor

slozier commented Feb 21, 2026

I guess I didn't explain myself well regarding my alternate solution. I meant only keeping the global using for pre .NET 9:

#if !NET9_0_OR_GREATER
global using Lock = System.Object;
#endif

so that using Lock would still require a file-scoped using System.Threading on .NET 9+.

@slozier slozier merged commit 5390e89 into IronLanguages:main Feb 21, 2026
8 checks passed
@BCSharp BCSharp deleted the fast_lock branch February 21, 2026 17:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants