Re: pthread_spin_lock

[email protected] Fri, 2 Feb 2007 06:25:00 +0100 (CET)
Newsgroups gmane.linux.real-time.rtlinux.general
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Not an SMP box actually. I was trying to test my box's capabilities
> according to Dr. Dobb's article (http://www.ddj.com/dept/cpp/184401780)
>
> But this one works:
>
> *(a)*
> Thread A
>  pthread_spin_lock(&lock);
>  sem_post(&sem);
>  clock_gettime(CLOCK_REALTIME, &start);
>  pthread_spin_unlock(&lock);
> Thread B
>  sem_wait(&start_sem);
>  pthread_spin_lock(&lock);
>  clock_gettime(CLOCK_REALTIME, &end);
>  pthread_spin_unlock(&lock);
>
> I don't understood the meaning of semaphore usage so I coded without them.
> sem_post doesn't make switching to threadB immediately. One way is making
> ThreadB higher priority but it makes latency latency higher. I tried it with
> mutex instead of spinlock.
>
well that one will work without the spin_lock/unlock as the 
sem_wait/sem_post will serialize thread A/B.

If you configure the box as SMP on a UP box you can have problems with 
using spinlocks - so just check if you configured it as SMP. a spin_lcok 
on a UP is simply a "disable-interrupts" - but if you configured it as SMP
box it actually will use a spinlock mechanism and thus could deadlock if a 
high prioirty task tried to aquire a spinlock held by a low priority 
process - the high priority process will simply spin on the lock for ever 
waiting for the low priority process to continue execution on "the other 
CPU" which does not exist on the UP ;)

hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFFwssunU7rXZKfY2oRAjZWAJ0Xixn618uRk209PT4aNHlemaXJAgCdEqDU
L0YTt2DqLcPq9mFaHaHUV0I=
=JlK0
-----END PGP SIGNATURE-----
_______________________________________________
Rtl mailing list
[email protected]
http://hq.fsmlabs.com/mailman/listinfo/rtl
http:/www.rtlinux-gpl.org/