* [ECOS] I/O thread safety
@ 2009-09-15 11:12 Stanislav Meduna
2009-09-15 12:09 ` Chris Holgate
0 siblings, 1 reply; 4+ messages in thread
From: Stanislav Meduna @ 2009-09-15 11:12 UTC (permalink / raw)
To: eCos Discussion
Hi,
I'd like to ask whether and how is the thread-safety
of the I/O subsystem approached - is this a problem
of application code, each subsystem, each driver,...?
I am implementing a driver for a CAN controller
connected via a SPI interface. Each CAN controller
transaction requires a few separate SPI transactions
that should not be interrupted by transactions done
from another thread (this can be probably fixed
to do everything in one SPI transaction, but
I'd like to ask anyway).
I am accessing the driver via the CYGPKG_IO_CAN layer.
The reads are normally executed by a message event loop
in one thread blocking until a CAN message arrives,
the writes are done from another thread.
To make things even more interesting both the SPI
and the CAN device are interrupt-driven...
What is the suggested approach to make this thread-safe?
A pointer to some example code is enough.
Thanks
--
Stano
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] I/O thread safety
2009-09-15 11:12 [ECOS] I/O thread safety Stanislav Meduna
@ 2009-09-15 12:09 ` Chris Holgate
2009-09-15 13:42 ` [ECOS] Devfs ioctl's Green, Neal
0 siblings, 1 reply; 4+ messages in thread
From: Chris Holgate @ 2009-09-15 12:09 UTC (permalink / raw)
To: Stanislav Meduna; +Cc: eCos Discussion
Stanislav Meduna wrote:
> Hi,
>
> I'd like to ask whether and how is the thread-safety
> of the I/O subsystem approached - is this a problem
> of application code, each subsystem, each driver,...?
>
> I am implementing a driver for a CAN controller
> connected via a SPI interface. Each CAN controller
> transaction requires a few separate SPI transactions
> that should not be interrupted by transactions done
> from another thread (this can be probably fixed
> to do everything in one SPI transaction, but
> I'd like to ask anyway).
The generic SPI layer has a mutex which protects the bus between calls
to cyg_spi_transaction_begin and cyg_spi_transaction_end, so you can
assemble an atomic series of SPI transfers fairly easily. You can
either hold the chip select for the device for the duration of the
entire transaction or use the 'drop_cs' parameter in
cyg_spi_transaction_transfer in order to release the chip select between
transfers. Of course this assumes that you're accessing the SPI API
from thread context and not DSR handlers from the CAN driver.
Chris.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] Devfs ioctl's
2009-09-15 12:09 ` Chris Holgate
@ 2009-09-15 13:42 ` Green, Neal
2009-09-15 15:58 ` [ECOS] " Grant Edwards
0 siblings, 1 reply; 4+ messages in thread
From: Green, Neal @ 2009-09-15 13:42 UTC (permalink / raw)
To: eCos Discussion
This is my first post to this list so I hope I did it right.
I'm porting a driver to eCos but the io subsystem doesn't provide ioctl.
We don't want to have to change all of our ioctl calls in our
applicatons. I see that other drivers have ioctl functions - what's the
correct way to handle this situation?
-Neal
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] Re: Devfs ioctl's
2009-09-15 13:42 ` [ECOS] Devfs ioctl's Green, Neal
@ 2009-09-15 15:58 ` Grant Edwards
0 siblings, 0 replies; 4+ messages in thread
From: Grant Edwards @ 2009-09-15 15:58 UTC (permalink / raw)
To: ecos-discuss
On 2009-09-15, Green, Neal <Neal.Green@PERKINELMER.COM> wrote:
> This is my first post to this list so I hope I did it right.
Well, since you asked, not quite. You "hijacked" a thread by
replying to a posting and changing the subject. The problem
with that is that your post shows up as part of the thread to
which you replied. If somebody has decided they're not
interested in that thread and killed it, then they won't see
your posting even though it has nothing to do with the killed
thread to which you posted it.
IOW, changing the subject doesn't start a new thread. To start
a new thread, send a "fresh" e-mail to the list (rather than
replying to a message in an existing thread).
> I'm porting a driver to eCos but the io subsystem doesn't
> provide ioctl. We don't want to have to change all of our
> ioctl calls in our applicatons. I see that other drivers have
> ioctl functions - what's the correct way to handle this
> situation?
--
Grant Edwards grante Yow! I'm RELIGIOUS!!
at I love a man with
visi.com a HAIRPIECE!! Equip me
with MISSILES!!
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-09-15 15:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-15 11:12 [ECOS] I/O thread safety Stanislav Meduna
2009-09-15 12:09 ` Chris Holgate
2009-09-15 13:42 ` [ECOS] Devfs ioctl's Green, Neal
2009-09-15 15:58 ` [ECOS] " Grant Edwards
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).