I am using Beagle Bone Black with Arch Linux ARM OS to communicate with ltc-6804 chip via SPI port. I have came to a point that the interrupt from the OS in the middle of sending read command and receiving measured values causing a trouble for me to get a valid measurement from the chip. Is there any way to "protect" the part of the code being interrupted on the run? In the other words, let the send and read section complete without any interruption.
This is a different approach to your problem, and is not about working within Linux. Instead it is about using other BeagleBone Black resources to solve the problem.
As well as the ARM Corex-A8, the BeagleBone Black also has two more processors, called Programmable Real-Time Unit Subsystem and Industrial Communication Subsystem (PRU-ICSS), often just PRU.
The two PRUs run independently of the ARM running Linux, and so are not affected by Linux scheduling; they won't be interrupted or pre-empted by Linux.
PRUs are intended for real-time processing, and have access to all I/O. They are RISC cores each running at 200MHz, so should be plenty fast enough, and be able to do anything you need. You could dedicate one to your SPI communication task.
They can be programmed in C or assembler. There are several useful articles on the web this one on Hackspace has useful links to key examples and technology. IIRC there are examples showing how to the main 'Linux processor' interacts with a PRU.
This is a course on using the PRU.
You are looking for the wrong solution to the problem. Fix the software properly instead.
SPI is completely synchronous. Since you're the master, you own the clock. With properly designed SPI routines, there should be no harm in interrupt stealing cycles arbitrarily. All that should do is stretch out time between transitions, which should not be a problem.
No interrupt should be taking 5ms, that is forever....
However, you might be being preempted, in which case you may wish to consider using one of the posix realtime schedulers instead of the default one, see the man pages for sched_setscheduler for details.
This is far more a software question then a hardware one however.