The latter. The result of that sort of race condition is unpredictable - there are “black box” issues with memory read and write latency and coherency, as well as scheduling and execution order.
In this particular case, recipient would be thread-local (ie. each thread would get its own copy) so it would equal 1. If it was really the same variable (same global address) you’d have a race condition and the results are pretty much undefined.
ok thanks for clarifing
ill have to design my solution again lol.
i am generating the normals for every vertex of the mesh,
the method is simple for every vertex, add the normals of all the faces it belongs to,
the result is a smooth shaded mesh.
what i was doing was mapping the triangles buffer so that each thread can represent one.
so each thread was equivalent to a triangle , and each one added its normal to each of the 3 vertexes it contains.
as you can expect, some vertexes are common between triangles, so when doing
vertex.normal += triangle.normal
i was expecting that they would have added correctly, well this is how you cannot do it then hehe.
ill try to get the other way round, mapping vertexes that “read only” the faces.
you can see the differences, on the wrong method normals are not fully completed, and some of them are seen as artifacts.
anyways, it surprised me that at least it looks very similar. i was specting really weird normal results.
in the end, even it looks similar, i wont use that method and as all suggested here, is just wrong and the results are not guarranted.