On 31-Jan-2018 11:36 PM, "Saket Sinha" <saket.sinha89@xxxxxxxxx> wrote:
>
>> However, I am using this in kthreads and I want to protect it without
>> using mutex/spilock.
>> Apart from protecting it with spinlock or mutex, is their anyway to
>> mark this dma buffer as read-only so that other threads(after
>> concerned thread has accessed it) cannot access the dma buffer.
>
> Basic locking theory states that if one section of code is already using one
> type of locking primitive, and you want a lock on the resource, you need to
> use the same type of lock, and the same instance.
>
I just love this above sentence, well put in a general sense, Valdis.
> In other words, you need to use a spinlock on dma_spin_lock as well, orThanks Valdis for the prompt reply.
> things *will* fail (and when it's a DMA controller in question, the failure will
> almost certainly be spectacular). So using a mutex is probably out of
> the question.
>
> Have you considered restructuring your code so a spinlock is usable?
>
I would go ahead and check if spinlock could work instead of mutex
which I am currently using.
However, let me also explain the context how I am using mutex by below
pseudo code-
MUTEX_INIT(dma_lock);
void dummy_worker_thread()
{
...................
mutex_lock(&dma_lock)
CHECK_BIT(hw_register, nth_bit);
mutex_unlock(&dma_lock);
....................
}
Lets suppose the nth_bit is set in hw_register every X ms.
Do you think spinlock will be more advantageous here than mutex ?
See basic difference between mutex and spinlock is, the former puts the thread waiting on the lock to sleep and later does a busy wait.
Since the nth bit is set every X ms, I think sleeping and waking up would turn out to be costly operations/overhead so no mutex. Spinlock would be good enough here.
Note: I am on ARMv8 SMP system using kernel version 4.4 .
Regards,
Saket Sinha
Regards,
Saket Sinha
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/ kernelnewbies
- Rohan
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
