public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [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).