Chief Delphi - Suggestion for next year's WPILib

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- C/C++ (http://www.chiefdelphi.com/forums/forumdisplay.php?f=183)

- - Suggestion for next year's WPILib (http://www.chiefdelphi.com/forums/showthread.php?t=84628)

Re: Suggestion for next year's WPILib

If the auto thread is politely behaved and checking a cancel or other notification, what is the benefit in forking a thread and killing it. It seems to me that the big benefit of killing the thread is to handle code that is spin-locked, yielded, looping to home in on a target, or otherwise not well-behaved.

Statistically, killing the thread will usually work, but if the thread has acquired a mutex, allocated I/O or other other OS resources, how is a chaperone to know what to delete, what to leave open, what to unlock. Plus depending on the implementation, the lock and other items may have thread-local storage, which means the info has been torn down and the chaperone doesn't have the ability to clean up. If enough shadowing is done with WPILib, those resources can be made safe for killing. OS resources would still be an issue, but should be sufficiently rare I'd think.

Greg McKaskle

Re: Suggestion for next year's WPILib

Quote:

Originally Posted by mikets (Post 943331)

It's good in theory but I do worry students may not understand multi-threaded programming. They need to learn inter-thread synchronization and exclusive access (e.g. semaphores). BTW, is it true that semaphores in vxWorks is not counting semaphores? I can't acquire the semaphore again in the same thread?

VxWorks has counting semaphores, binary semaphores and mutex semaphores. The C functions to create them are semCCreate, semBCreate and semMCreate. After creation semTake and semGive are used for all 3 types. I think the POSIX semaphores are really VxWorks counting semaphores. The POSIX mutexes are implemented using VxWorks mutex semaphores.

VxWorks also has public (inter-process) versions of all these types but we don't use them for FIRST (processes are not used, just kernel mode tasks/threads)

Hope this helps

Re: Suggestion for next year's WPILib

Quote:

Originally Posted by Greg McKaskle (Post 946602)

VxWorks will release mutex semaphores when a task dies if that flag is set when the semaphore is created. But in general, VxWorks does no cleanup (freeing memory, closing files, etc) when a task dies.

Hope this helps

Re: Suggestion for next year's WPILib

I have a different suggestion for WPILib & WPILibJ:
Make WPILib & WPILibJ as close to the same as possible (and make them make more sense)
also, having WPILib and WPILibJ have the same version number would be nice
Although I have only looked at the Dashboard and Driverstation classes, they are quite a bit different (and helped cause this error http://www.chiefdelphi.com/forums/sh...2612&page=2#20)
2010:

Code:

C++

dash = DriverStation::GetInstance()->GetHighPriorityDashboardPacker();



dash.Printf("%s",data.c_str());//this sends it as well



Java



dash = DriverStation.getInstance().getDashboardPackerHigh();



dash.addString(data);//this does not send it

dash.commit();

Ideal world (2011?)

Code:

C++

dash = DriverStation::GetInstance()->GetHighPriorityDashboardPacker();



dash.AddString("%s",data.c_str());

dash.Send();



Java



dash = DriverStation.getInstance().getHighPriorityDashboardPacker();



dash.addString(data);

dash.send();

Re: Suggestion for next year's WPILib

Printf() and AddString() are not the same function. C++ has AddString() too, and a function that does the same thing as commit().

But they should be consistent with naming, I guess.