Add AtomicI32 and AtomicU32.

[mahkoh]

No description provided.

[eddyb]

Would be nice if AtomicX were changed to Atomic<X>.

[Manishearth]

Implemented at rust-lang/rust#23572

+1

@eddyb Any sort of trait bound we need to place on X for that? I like this idea.

[eddyb]

@Manishearth well, yes, you'd use a trait that you implement only for a few types.
The only problem is AtomicBool, which is implemented as AtomicUsize with 0 for false and !0 for true.
I'm not sure if using atomic operations on bool directly would be undesirable or unsupported (on some platforms).

[Manishearth]

So would this trait be implementable on external types? Eg one might want to slap the trait onto our wrapping types -- would that (could it?) be possible?

What methods would one need to provide, if any?

[eddyb]

@Manishearth well, if that's allowed then it has to be unsafe, and maybe instantiating the intrinsics could error - but that feels brittle.
I think there's a reason we have so few atomic types (aren't they all effectively usize?), namely portability of atomic operations on more specific types, which worries me about the possibility of ever doing some nice unification.
There have likely been previous discussions about this, but I'm not sure where to start looking.
cc @alexcrichton

[reem]

Is there an alternative in here?

[mahkoh]

No. Such freestanding functions would have to be intrinsics (not wrappers) and would have to be unsafe.

[alexcrichton]

There have likely been previous discussions about this, but I'm not sure where to start looking.

Two worries I've had about Atomic<T> in the past are that we'd need a trait here, but it's not clear whether the trait should be public or how it should be implemented (as you've brought up). The other is that the current API of AtomicUsize is pretty different from that of AtomicBool and AtomicPtr (e.g. the latter two do not have fetch_foo).

---

Specifically on the topic of AtomicU32, I am not 100% sure of the portability of this. It is a commitment that the underlying platform will be able to support atomic operations on a 32-bit field, which may not always be guaranteed to fit in a usize (which we are committing to support). For example a 16-bit platform may have a tough time supporting 32-bit atomic operations (but I am not sure on this!).

@mahkoh could you investigate the story here a bit more? I'm curious if committing to these 32-bits would hurt our portability in any way, and if so it should be mentioned in the RFC.

[mahkoh]

You're not allowing people to

• use assembly
• use atomic intrinsics
• link to llvm intrinsics

in 1.0 stable. You're the one who is forcing this commitment on the standard library by making it the only place where atomics can be implemented.

For example a 16-bit platform may have a tough time supporting 32-bit atomic operations (but I am not sure on this!).

This isn't javascript. If you want Rust to be called a systems language (and with the lack of inline assembly that's already a stretch) then you have to allow people to write non-portable code. It's pretty amazing that the only way to do this right now is to link to non-Rust code.

[nikomatsakis]

@mahkoh

You're the one who is forcing this commitment on the standard library by making it the only place where atomics can be implemented.

I think by this you mean that we are being conservative with respect to what we include in 1.0. I don't really see a problem with that. No 1.0 release is meant to be all things to all people (or, at least, no 1.0 release that ever actually gets shipped). We'll expand capabilities over time, but I don't see why we should commit too early to assembly or intrinsics.

That said, it seems obvious that we will want 32-bit atomics in the stdlib at some point. And while I would like to support 16-bit CPUs to the extent we can, I don't want to let the perfect be the enemy of the good either. 16-bit CPUs seem like a distinctly more specialized market that 32-bit or 64-bit, so it feels a bit silly to limit libstd to just those things that a 16-bit CPU can support natively.

[eddyb]

@alexcrichton is there some known reasoning for backing AtomicBool on usize?
I'm guessing it could be that some platforms might not support u8 atomics.
If we have to deal with such issues, I expect Atomic<T> to use a trait with an associated type that represents the "smallest integer (that can hold the value range) with atomic support on the current platform".

Actually, AtomicBool feels like a waste. Maybe there should be something based on bitflags! that supports atomic operations.

[alexcrichton]

@alexcrichton is there some known reasoning for backing AtomicBool on usize?

The only reason I know of is that it's basically just the way it's always been. I do not know of the implications of supporting atomic intrinsics that operate on bytes, but it would probably just require some #[cfg] in the stdlib.

[tbu-]

@alexcrichton AtomicUsize is a compatiblity hazard already, intel 16 bit processors can't do it. Not sure why we should "suddenly" care about 16 bit platforms when we haven't in the past (usize must be 32 bit there due to the segmented addressing scheme that requires 20 bit per address).

If we really care about portability to those platforms, we probably have to distinguish between size_t and uintptr_t like C does.

[alexcrichton]

Not sure why we should "suddenly" care about 16 bit platforms when we haven't in the past

I expect an RFC to thoroughly explore the design space and constraints of what it is proposing to understand the tradeoffs associated with it. I'm only requesting that this topic be investigated and mentioned for completeness, I do not want to block additions to the standard library on the basis of 16-bit support.

[carllerche]

Just throwing out that AtomicU32 could still be present on 16bit systems by using a lock of some sort on those systems.

[aidancully]

@carllerche I'm inclined to disagree. That assumes that such a lock is possible to implement. A hardware DMA will ignore a CPU lock, and may get an inconsistent view of a U32 if it takes multiple transactions to store the U32 in memory. This seems contrary to expectation when working with "atomic" types. On the other hand, a 16-bit write would be atomic even to a DMA when all 16 bits can be written in a single memory transaction.

[bill-myers]

Most/all 16-bit usize platforms are single processor, which means they can implement any sort of atomics (by disabling interrupts if in kernel space or by completing the operation in the kernel before switching tasks if in user space).

This doesn't work if you are in user space and the kernel can't be modified and doesn't support atomic emulation, but that seems unlikely considering that a system with <64K RAM can't really run any complex off the shelf kernel.

It's not atomic WRT MMIO devices, but that doesn't matter for portable code.

[kmcallister]

You're the one who is forcing this commitment on the standard library by making it the only place where atomics can be implemented... This isn't javascript. If you want Rust to be called a systems language (and with the lack of inline assembly that's already a stretch)

Chill the hell out; this attitude is not welcome. You've been warned about it many times in the past. And don't think I forgot about your pointless name squatting on crates.io. You seem to go out of your way to antagonize the Rust developers and community whenever you find a minor, fixable bug that annoys you personally.

Unfortunately the precedent is that the code of conduct can't really be enforced against a regular contributor. I hope the core team has learned from these past mistakes and will handle the present situation differently. Until I see evidence of that, about all I can do is speak up in public. Please spare me any lectures on the impropriety of addressing this in the open.

Edit: Wow, I didn't even see #1007 when I wrote this comment.

[mahkoh]

You've been warned about it many times in the past. And don't think I forgot
about your

This kind of language might work on your children, but it doesn't work on people
you've no legitimate authority over.

Unfortunately the precedent is that the code of conduct can't really be
enforced against a regular contributor.

Too bad. If you wanted a code of conduct that can actually be enforced, you
would have to write one that isn't one big ambiguous clause. The current CoC
wouldn't become any less effective if it were replaced by "Be nice."

Such a CoC cannot be enforced in anything but the most extreme cases without
generating tons of arguments. Did you know that, according to some
interpretations, you're in violation of the CoC right now?

Likewise any spamming, trolling, flaming, baiting or other attention-stealing
behaviour is not welcome.

That's right, by sliding this topic into an off-topic discussion, you're
stealing attention from the content of the RFC that some people might want to
discuss. Of course, we don't have to read that far, "trolling" can already be
applied to anything:

• Things you disagree with
• Things you agree with (concern trolling)

Then there is this paragraph:

Respect that people have differences of opinion and that every design or
implementation choice carries a trade-off and numerous costs. There is seldom a
right answer.

Which is nothing but the golden mean fallacy.

Until I see evidence of that, about all I can do is speak up in public. Please
spare me any lectures on the impropriety of addressing this in the open.

If you think that I am against people speaking their minds publicly then you
haven't understood anything. The "past mistakes" were caused by a lack of
transparency and a lack of people willing to honestly speak their minds
publicly.

The team is currently applying a policy never to offend anyone, never to call
an idea bad, and never to take a clear stance as early as possible. What you're
calling "past mistakes" is just one example of that: A situation that was left
simmering for a year and that didn't have its root cause addressed.

Of course, you think that you're without fault here and that, as long as
everyone follows the CoC, everything can work smoothly and everyone can be
happy. You're ignoring that this policy creates a breeding ground for passive
aggressive behavior. Without in-person interaction, you're relying solely on the
goodwill of others to interpret your unclear statements and actions. If this
goodwill is not there or, due to cultural differences, your behavior is
interpreted incorrectly, then you might look like the one who is being passive
aggressive or who is wasting the other person's time intentionally. See
this for an example of such differences.

If this happens often enough, then the goodwill gets used up and people will
automatically assume the worst and act aggressively themselves. You think that
I'm going out of my way to antagonize you, but that's just your interpretation.
From my perspective I'm acting appropriately given the way I feel I'm being
treated.

• Endless ignoring of PRs: This PR was open without a comment for
  almost 45 days and it's not the only one of its kind. If a PR is not going to
  be accepted, then it should be closed after two or three days with a clear
  statement that tells you what has to be done to get it in or that something
  like that will never get in.
• Inappropriate closing of issues: This issue complains in its title
  that cargo test is slower than rustc --test. The issue was then closed
  with the comment that I should simply configure cargo test to not run
  rustc --test which is incorrect advice even if one has just read the title
  of the issue. This might have been a mistake, but being told by a core team
  member to open a new issue instead of them reopening it themselves is nothing
  but passive aggressive behavior.
• False incentives: This issue told me that my RFC was accepted and I
  took the opportunity to implement it as written. Opened a PR, got feedback,
  fixed the issues, even discussed the finer details of variance at length with
  @nikomatsakis. Only then to be told on IRC that merging the RFC in that form
  was a mistaken and that I'd probably have to expand and rewrite parts of the
  implementation.
• A lack of transparency: When major decisions are made behind closed doors
  without any kind of transparency, then you cannot claim that this is a
  community project. The RFC process is a nice circus show, but the decisions
  actually happen long before anything goes there and the decision process is
  completely opaque. This RFC was merged without the discussion
  being made public. Was there a voting process? Who voted for what? What points
  were discussed? What points were ignored? "the core team has decided to"
  Yupp, the "core team" is an opaque entity that has only one opinion and there
  was no need for a discussion.

"You're treating your volunteers like shit" is not an overstatement.

And when @alexcrichton posts bullshit like telling me to "investigate" the
influence of 32 bit atomic operations (in a "systems language"!) on portability
to all potential platforms and to "explore the design space" then it's
impossible to know if this is just another one of his passive aggressive games
trying to waste my time and stall the RFC or if he's actually serious.

Now go ahead and "enforce the CoC." I've said everything I had to say.

[Manishearth]

Did you know that, according to some
interpretations, you're in violation of the CoC right now?

Lay off. This is like the fallacious "Giving you freedom to do X violates my freedom to not be surrounded by people who do X" argument that's seen often these days. kmc is pointing out behavior they find unwanted, which is totally okay. There's no ad hominem or anything there.

Of course, you think that you're without fault here and that, as long as
everyone follows the CoC, everything can work smoothly and everyone can be
happy.

I've said this multiple times before, and I'll say it again: In my experience, having civility rules is less harmful in the long run than not. More details here if you want something to back that assertion up.

If the CoC is changed so that civility is no longer expected on Rust projects, I will be leaving. So will others, afaict. I also feel that it and its execution can be improved, but that's tangential.

Without in-person interaction, you're relying solely on the
goodwill of others to interpret your unclear statements and actions.

Which is why one should be pretty clear on the Internet. You have a tendency of not doing so, though this has improved lately :)

Endless ignoring of PRs

Your example shows that huon asked for a test, which you didn't provide, and later closed the issue yourself.

FWIW it's hard to keep track of issues and PRs, and stuff does get missed often. Now with the assignee system hopefully that's less of an issue, but it may still happen. Just ping someone in IRC for review, or on the issue.

If a PR is not going to be accepted, then it should be closed after two or three days with a clear statement that tells you what has to be done to get it in or that something like that will never get in.

This actually happens all the time. Your PR is not an example of this.

Inappropriate closing of issues:

Your title is vague and addresses the wrong issue. It is unclear what you want done about it; and you should open a different issue if the underlying issue has changed. Nothing passive aggressive about that. It's harder to find duplicates and triage when issues have misleading/vague names.

False incentives:

That sounds like a mistake in the acceptance; that the RfC was accepted prematurely. This can happen -- just because an RfC is accepted doesn't mean that we should turn a deaf ear to new doubts on the design. It's hard to gauge when an RfC has reached its saturation in doubts raised; just seems like more people noticed the PR than noticed the RfC. Meh.

A lack of transparency: This RFC was merged without the discussion being made public. Was there a voting process?

What discussion? I see pages of discussion on that page, along with more pages on the original RfC. The core team tries to gauge consensus on the RfC (from what I've seen this is in IRC or in the weekly meetings, both of which are publicly logged), and I don't think they vote. Aaron's comment gives a pretty good idea of how they gauged consensus.

And when @alexcrichton posts bullshit like telling me to "investigate" the
influence of 32 bit atomic operations (in a "systems language"!) on portability
to all potential platforms and to "explore the design space" then it's
impossible to know if this is just another one of his passive aggressive games
trying to waste my time and stall the RFC or if he's actually serious.

No, he's right. It is a portability issue. It's not one which might block the RfC, but it's one which should be considered. Your arguments about this being a systems language are a straw man -- Rust does support these atomics via intrinsics, but not stable Rust. Stable 1.0 Rust was never meant to be all the things. But once you mark something as #[stable], there's no going back, so he's asking for some more background on this so as to make a more informed decision.

I'm going out of my way to antagonize you, but that's just your interpretation.
From my perspective I'm acting appropriately given the way I feel I'm being
treated.

I read that as "Don't assume malice on my part -- I may be assuming malice on your part"

It doesn't really matter who was originally at fault, causing the other party to get antagonized. What matters is that everyone should just calm down, stop assuming malice on any side, and try to be more precise in their communications.

Can we get back to writing code and being awesome, please?

[nikomatsakis]

OK, woah, things seem to have gotten rather out of control here. I think we should all take a step back for a second.

@mahkoh, I'm sorry that you decided to close this RFC. I wanted to see it land, since it seems clear that there will be a need for Atomic[UI]32 at some point. I don't believe that @alexcrichton (or anyone else) was attempting to stonewall you, though it may have seemed that way. As Alex said here, he simply wanted some text indicating what level of support for 32-bit operations exist on 16-bit platforms, which I think is a legitimate request. (And, in fact, I think the comment thread supplied a large part of that background.) In particular, the portability of the operation might determine where it falls in the stdlib hierarchy -- we haven't fully settled conventions on architecture-dependent features.

With respect to prioritization and PRs that sit for some time, I know it's frustrating, but delays do happen. I certainly acknowledge that I have been guilty of letting RFCs and things sit in the past (and in the present). We all have a lot of demands on our time and we're trying to pull a release together; this can lead to things being overlooked or deprioritized. It's unfortunate but true. To some extent, this is just a fact of life, but we've also been thinking it would be good to tweak our decision-making process to help it scale better. We have actually been working for some time now on a revised "governance proposal" that we plan to bring forward soon, though certainly not till after the beta period is over (we've got other things to focus on right now).

I'd like to also respond briefly regarding transparency. The reason that the core team does not write out votes when writing about a final decision is fairly simple: there aren't any. The core team discussion is not about "new" analysis; rather, we try to focus on the pros/cons that were raised in the discussion, and be sure that every objection was satisfactorily addressed (we also don't vote; we operate on a consensus-based model). If we do uncover new objections, then we write those in the thread and postpone making a decision until there has been a chance to respond. In other words, the discussion takes place in public -- even private IRC discussions should be transposed into the RFC so that they can be commented on. This hasn't always been the case, but we've been working pretty hard on it, and I think it's been working pretty well: I know that the quality of the RFCs has risen due to the increased community feedback.

Finally, regarding the code of conduct. I am a firm believer in the principle that, in most technical debates, there is no single right answer, and that every decision involves tradeoffs. I think that the Rust language itself is really based in this principle, which is why we frequently surface implementation decisions (like what memory management strategy to use) up to the programmer, rather than offering a single "one size fits all" abstraction. The goal of design discussions therefore is to uncover and understand these tradeoffs, and find the way that we can cover as many of them as we can without undue complexity. This goal is best aided by having a welcoming, diverse community, and the Code of Conduct is an important part of making that happen.

That said, I tend to agree that the Code of Conduct as written is somewhat incomplete. It lays out the principles that we want but is relatively silent on the topic of how it is to be enforced. To address this, the "governance proposal" I discussed is intended to include an enforcement plan that will hopefully clarify such matters. Perhaps we can save further dissection of the CoC's language until then.

PS. I nominate "write code and and be awesome" as official Rust slogan.