"Can't obtain network semaphore"

[Till Straumann]

Steve Holle wrote:
> I bit the bullet and undefed RTEMS_FAST_MUTEX and recompiled this 
> morning and now I get the error message :
> RTEMS: Can't obtain network semaphore: `object deleted while waiting'
> 
> Does this give us any more details?

No. That's consistent with the error code # 4 you observed earlier.

It's strange. I really couldn't find any other place for this
being set to 4 other than rtems_semaphore_delete()
[which calls _CORE_mutex_Flush(..., CORE_MUTEX_WAS_DELETED /* == 4 */)]

> How can I trap on that specific semaphore being deleted, as I don't 
> think it ever should.

Try to break in _Thread_queue_Flush at the line

the_thread->Wait.return_code = status;

(you could make this a conditional break subject to status == 4)

-- Till
> 
> At 03:22 PM 12/15/2004, Eric Norum wrote:
> 
>> Joel Sherrill  wrote:
>>
>>> I still wonder if there is really any value to not calling the
>>> real semaphore services.  I thought the direct use of score services
>>> was just temporary for comparison and speed improvement until
>>> we had the optimizations in semaphore.
>>> Chris/Eric what do you guys remember?
>>
>>
>> IIRC we put in the 'fast mutex' stuff because it made a significant 
>> impact on the network performance (for EPICS at least).   Perhaps it's 
>> no longer the case.  I'd be happy to remove the fast mutex stuff -- it 
>> always felt a little like I was poking into places I ought not....
>>
>> -- 
>> Eric Norum                                 norume at aps.anl.gov
>> Advanced Photon Source                     Phone: (630) 252-4793
>> Argonne National Laboratory
> 
> 
> Steve Holle
> Link Communications, Inc.
> 1035 Cerise Rd.
> Billings, MT  59101
> sholle at link-comm.com