Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Except for a blog post here and there, describing the custom attributes someone created, but that do not seem to get any traction - like one describing how to enforce immutability, another one on Documenting Thread Safety, modeling the attributes after JCIP annotations - is there any standard emerging? Anything MS might be planning for the future?

This is something that should be standard, if there's to be any chance of interoperability between libraries concurrency-wise. Both for documentation purposes, and also to feed static / dynamic test tools.

If MS isn't doing anything in that direction, it could be done on CodePlex - but I couldn't find anything there, either.

<opinion>Concurrency and thread safety are really hard in imperative and object-languages like C# and Java, we should try to tame it, until we hopefully switch to more appropriate languages.</opinion>

share|improve this question

migrated from Nov 11 '11 at 16:47

This question came from our site for professional and enthusiast programmers.

Vote to move to programmers for how opened ended this is – user7550 Aug 17 '11 at 18:19
up vote 3 down vote accepted

The problem with both immutability and thread safety are that they are not black and white concepts, but there are a number of possible guarantees in that regard. Reducing that to simple attributes might be hard. IMO a simple ThreadSafe and Immutable attribute isn't enough. Still working out a set of attributes capturing at least the most important semantics sounds promising to me.

For example take an AddRange method. It might be thread safe enough to never corrupt the state of the underlying collection, but might not be atomic. A common implementation with these properties might be just calling an atomic Add method for each element.

On the immutability side we have different aspects too:

  • Offering only readonly accessors or truly never changing
  • Depth of immutability i.e. are sub-objects immutable too
  • Physical vs. logical immutability. For example lazy initialization does not change the visible state, but changes the internal state.

One annotation is this context already exists: Pure for side effect free methods.

share|improve this answer
I agree that it is not simple. But I think it should be done. It's too hard to do complex software without it, especially integrating multiple libraries. Thanks for pointing out Pure (…), that's a start and I'll therefore accept your answer, as it seems to be the best we can get right now, in terms of an 'quasi-standard' of at least SOMEthing. – Eugene Beresovksy Sep 2 '11 at 2:12

I don't think there's a set of standards (even quasi) right now. Isolated projects do some of this in their own way. In a thread post they talk about immutability via code contracts and even baking directly into the type system. I've seen even less about thread safety.

share|improve this answer
If every project implements their own system, it's hard to integrate different libraries and build or use static / dynamic analysis tools to verify things. – Eugene Beresovksy Sep 2 '11 at 2:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.