Is there possibility of data race during operating this data structure?

Yes there is. Add and Remove are not safe to call in a concurrent context. Is it sufficient to document this? The expected use of Add and Remove follows the examples in this package, mutating "owned" references as in:

func myCoolFunction() cpuset.CPUSet {
    result := cpuset.NewCPUSet()
    for i := 0; i < 10; i++ {
        result.Add(i)
    }
    return result
}

If a doc update isn't sufficient, I would prefer not to add an RWLock to this type. Another option could be to encode the expected use by creating a mutable builder type from which the user can retrieve the immutable result CPUSet (I quite like this idea). That could look something like this:

func myCoolFunction() cpuset.CPUSet {
    builder := cpuset.NewBuilder()
    for i := 0; i < 10; i++ {
        builder.Add(i)
    }
    return builder.Result()
}

Updated; added Builder and made CPUSet immutable outside of the cpuset package.

Thanks, the builder design make sense

Do you think it make sense to use uint64 or uint32 instead of int?

How about just uint, which is guaranteed to be at least 32 bits wide?

I'm not totally convinced it's worth it to use an unsigned type here, in terms of the inconvenience to calling code. In practice, on any real system the valid elements are already a tiny subset of int, and int is similarly guaranteed to be at least 32 bits wide.

sgtm

👍

It seem ToSlice() sounds better here.

No opinion either way on this, will update.

Renamed to ToSlice()