The 68k, like most CISC processors, does read-modify-write cycles atomically (together). This is used on the Amiga extensively for incrementing/decrementing library open counts for example.
Actually, bset/bclr or addq are not atomic, at least not in the sense the word is used today. A second bus master could intercept the instruction at any time and then observe Os structures in an inconsistent way. Except that such bus masters are absent on the Amiga as single-core machine.
Library open counts are, however, not really secured due to atomicity of addq/subq, but are rather Forbid/Permit locked. Or actually, the whole story is a bit more complicated, as library open consists of the low-level exec function which is forbid-locked, and a high-level ramlib add-on which is patched in by the system itself as soon as dos becomes available. Then, however, locating libraries is due to the single-threaded ramlib task to which exec (or rather, the ramlib patch on top of exec) communicates. Thus, this is a pretty complex beast and had, as of 1.3, quite a couple of loopholes.
addq/bset and friends are thus less often used by the Os as one may think. In fact, if you are writing in a higher level language, one cannot guarantee that the compiler emits the right instructions in first place (unless you're using C++11, which does have atomic variables. "atomic" in the real sense. Of course, there is no such compiler on the Amiga.)