Cyg_Alarm::initialize not thread (DSR) save

[Reinhard JESSICH]

We have two threads in our application which will initialize / disable the same alarm.
The threads have different priorities.
Sometimes we had troubles with a corrupted alarm_list in the counter.

After a long time of testing we found, that the lower priority thread calls Cyg_Alarm::initialize
and gets interrupted just after "if( enabled ) counter->rem_alarm(this)" by the higher
priority thread. The higher priority thread calls Cyg_Alarm::initialize with the same timer and
go to sleep. Now the lower priority thread continues its work and executes
"counter->add_alarm(this)" a second time on the same timer. After the last step the list
is currupted. We use multi list timers, but I think the problem occures with single list timers, too.
Because Cyg_DNode::insert can not deal with nodes which are allready in a list and are inserted
again.

We solved the problem with a mutex in our application, but from my point of view the kernel
should be save. If in the above example a DSR is used instead of the higher priority thread
the same problem will occur and it can't be solved with a mutex. Then the application have to
lock/unlock the scheduler befor executing Cyg_Alarm::initialize. And I don't think it is good
practice lock/unlock the scheduler from an application.

My suggestion is to modify "Cyg_Alarm::initialize" according to my attached patch (lock/unlock
the scheduler).
The patch is against current CVS and shall be applied in "packages/kernel/current" with
option -p0.

BR
   Reinhard


-- 
 Ing. Reinhard Jessich                Phone: +43/1/81150/2395
 Software Design                      Fax: +43/1/81150/3169
 Frequentis Nachrichtentechnik GmbH   A-1120 Wien, Spittelbreitengasse 34
 http://www.frequentis.com            eMail: rjessich@frequentis.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: initialize.pat
Type: application/octet-stream
Size: 1923 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/ecos-patches/attachments/20030627/d294ff14/attachment.obj>