It can be both but the fundamental problem is that all the bits are read, even if only one is being checked and all the bits are written, even if only one has changed. Imagine you write 0xFF to a port then read it back, you would expect 0xFF as the result but what you actually get is the state of the port pins which could be influenced by outside circuits. Similarly, using the OP's code, " if(PORTB.F1==1)" reads the current state of ALL the port bits, including ones not relevant to the code and "PORTB.F0=0;" writes to all the port pins. If the level on any other pins changes, it is possible for the wrong level to be written out again.
On PIC18F and later MCUs a different port structure is employed and writing goes to the port's LAT register while reading is still done from the PORT register. It is still possible to write to the port and it will still work but the RMW problem might still occur.
It's an obscure problem that doesn't manifest itself in most applications but worth knowing about when unexpected IO values show up. The 'quick fix' is often just to put a NOP (= single cycle) instruction to allow the port contents to settle between write and read instructions. The better fix is to read the port into a variable, change the bits in the variable then write it back out again.
Brian.