[Marco van Herwaarden]

Have a look here (and many other pages): http://dev.mysql.com/doc/refman/4.1/...l-locking.html

Simply put:
MyIsam uses table level locking (ie. it doesn't lock a single row, but the entire table).
There are 2 lock wait queues: WriteLock and ReadLock queue.
Many simultaneous Read-lock can be placed on a single table at once.
Only 1 write-lock can be active on a table.
Writes get priority over reads.

Scenario A with searching and nobody is trying to write to the table:
The search is a longer running read, that places a read-lock on the table.
Others also want to read from the same table. This is not a problem since you can have multilple read-locks on the same table.

Scenario B with searching, 1 want to write to the table, and many others want also to read from teh table:
The search is a longer running read, that places a read-lock on the table.
A write request is made. A write-lock can not be obtained, since there is already a read-lock in place. So write is placed in the write-lock queue and waits for the previous read to finish.
Others also want to read from the same table. Since Writes go before reads, these new reads are placed in the read-lock queue, and will not be server until the write-lock queue is empty.

If you are unlucky with scenario B, new writes will be queued, while we are still waiting for the search to finish. Meanwhile the read-lock queue is building up, etc....

In some situations it might be advisable to change some tables from MyIsam (table-level locking, no transactions) to InnoDB (row-level locking, with transactions). Using this kind of tuning, requires probably an experienced MySQL-administrator.

PS A lot more documentation on tabletypes and locking can be found on this at the mysql.com website.