Am Mittwoch, 7. Dezember 2005 13:25 schrieb Luiz Fernando Capitulino:
> On Tue, 6 Dec 2005 23:36:47 +0100
> Oliver Neukum <[email protected]> wrote:
>
> | Am Dienstag, 6. Dezember 2005 22:18 schrieb Luiz Fernando Capitulino:
> | >
> | > Hi Pete,
> | >
> | > On Tue, 6 Dec 2005 13:02:07 -0800
> | > Pete Zaitcev <[email protected]> wrote:
> | >
> | > | On Tue, 6 Dec 2005 18:14:49 -0200, Luiz Fernando Capitulino <[email protected]> wrote:
> | > |
> | > | > The spinlock makes the code less clear, error prone, and we already a
> | > | > semaphore in the struct usb_serial_port.
> | > | >
> | > | > The spinlocks _seems_ useless to me.
> | > |
> | > | Dude, semaphores are not compatible with interrupts. Surely you
> | > | understand that?
> | >
> | > Sure thing man, take a look at this thread:
> | >
> | > http://marc.theaimsgroup.com/?l=linux-kernel&m=113216151918308&w=2
> | >
> | > My comment 'we already have a semaphore in struct usb_serial_port'
> | > was about what we've discussed in that thread, where question like
> | > 'why should we have yet another lock here?' have been made.
> | >
> | > And *not* 'let's use the semaphore instead'.
> | >
> | > If _speed_ does not make difference, the spinlock seems useless,
> | > because we could use atomic_t instead.
> |
> | You can atomically set _one_ value using atomic_t. A spinlock allows
> | that and other more complex schemes.
>
> We only need to set 'write_urb_busy', nothing more.
So go hence and encapsulate that using the existent infrastructure. Thus
you get the most efficient solution.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
