@cherusker,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

int is usually 32bit, and anyway, id is defined as guint, so we should change the type of next_generic_inst_id. I guess really we should change both to guint32, so we are always sure that it is 32bit? And then use InterlockedIncrement.

@lewurm, @lambdageek: so far, InterlockedIncrement (), InterlockedAdd (), ... is only defined for signed types (gint32 and gint64) in atomic.h. IMO, there are two options if next_generic_inst_id and MonoGenericInst:id should be unsigned (which makes a lot of sense of course):

A cast from guint32 to gint32 and back (with the increment in-between) seems to work fine on Fedora 26 (also with high numbers) and it might work in general. However, is there any guarantee that all supported compilers will always cast that as we fancy it (and don't cap it for example)?

#include <stdint.h>
#include <stdio.h>

int main() {

	uint32_t x = -3;
	int32_t y = x;

	for (int i = 0; i < 5; ++i) {
		x = ++y;
		(void) printf("x = %u, y = %i\n", x, y);
	}
	
	return 0;
}

My second idea is to add something like InterlockedIncrementUnsigned (volatile guint32 *val) to atomic.h as the need for such a thing might arise again. I played with atomic.h before (https://github.com/mono/mono/pull/5255/files#diff-e4e234bb2d8469fbeb2e3d1b467919ea) and think it shouldn't be much hassle. Picking the right name might be the most difficult part.

@cherusker you can just do InterlockedIncrement((gint32*)value)

Just make them signed, no need to use unsigned types unless necessary, it just complicates things.

Looks ok, please squash the changes when committing.

@vargaz I thought that all commits get squashed automagically when a PR gets merged and, due to that, I usually keep many small commits if somebody wants to retrace a specific PR. Anyways - just squashed everything :)

we can squash and merge on the github UI that does that

@monojenkins merge

cannot merge:

• "Linux i386" state is "success"
• "Linux x64" state is "failure"
• "OS X i386" state is "success"
• "OS X x64" state is "success"
• "Windows i386" state is "success"
• "Windows x64" state is "failure"