I wouldn't bet on it, especially on a busy multithreaded system, or if the dump location is on a network share (memorably, a professor would generate 8 GB core files that had to be spooled over 10Mbit ethernet via NFS). File system atomicity usually requires locking, or the write-to-a-temporary-file-and-then-
rename(1) trick. Some delving around in
fs/coredump.c for the linux 4.3.3 kernel indicates no such locking or rename tricks, as the kernel figures out the filename to use (with an unlinking race condition!) and then spools out the file:
core_dumped = binfmt->core_dump(&cprm);
Since there's probably no giant kernel lock to prevent other user-land things from running while the above is doing its business (this could be tested by slowing down the generation of a large core file, then seeing how that system behaves), I don't see anything atomic about this process.