Go to Post The real key to drive team coaching is to tie your jacket around your waist. Got a couple championship rings that way. - TravusCubington [more]
Home
Go Back   Chief Delphi > Technical > Programming > C/C++
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 31-03-2010, 22:54
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,753
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
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
Reply With Quote
  #17   Spotlight this post!  
Unread 05-04-2010, 00:13
wireties's Avatar
wireties wireties is offline
Principal Engineer
AKA: Keith Buchanan
FRC #1296 (Full Metal Jackets)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: Rockwall, TX
Posts: 1,170
wireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond repute
Send a message via AIM to wireties
Re: Suggestion for next year's WPILib

Quote:
Originally Posted by mikets View Post
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
Reply With Quote
  #18   Spotlight this post!  
Unread 05-04-2010, 00:16
wireties's Avatar
wireties wireties is offline
Principal Engineer
AKA: Keith Buchanan
FRC #1296 (Full Metal Jackets)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: Rockwall, TX
Posts: 1,170
wireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond reputewireties has a reputation beyond repute
Send a message via AIM to wireties
Re: Suggestion for next year's WPILib

Quote:
Originally Posted by Greg McKaskle View Post
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
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
Reply With Quote
  #19   Spotlight this post!  
Unread 13-04-2010, 18:07
byteit101's Avatar
byteit101 byteit101 is offline
WPILib maintainer (WPI)
AKA: Patrick Plenefisch
no team (The Cat Attack (Formerly))
Team Role: Programmer
 
Join Date: Jan 2009
Rookie Year: 2009
Location: Worcester
Posts: 699
byteit101 is a glorious beacon of lightbyteit101 is a glorious beacon of lightbyteit101 is a glorious beacon of lightbyteit101 is a glorious beacon of lightbyteit101 is a glorious beacon of lightbyteit101 is a glorious beacon of light
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();
__________________
Bubble Wrap: programmers rewards
Watchdog.Kill();
printf("Watchdog is Dead, Celebrate!");
How to make a self aware robot: while (∞) cout<<(sqrt(-∞)/-0);
Previously FRC 451 (The Cat Attack)
Now part of the class of 2016 at WPI & helping on WPILib
Reply With Quote
  #20   Spotlight this post!  
Unread 14-04-2010, 12:56
Al3+'s Avatar
Al3+ Al3+ is offline
ARTist
AKA: Anthony
FRC #0840 (Aragon Robotics Team)
Team Role: Programmer
 
Join Date: Oct 2009
Rookie Year: 2008
Location: San Mateo, CA
Posts: 58
Al3+ is a jewel in the roughAl3+ is a jewel in the roughAl3+ is a jewel in the rough
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.
__________________
cout << "Hello, robotics. Goodbye, world." << endl;

"The two-axis accelerometer provided in the kit of parts (shown in the picture below) is a two-axis accelerometer." - WPILib User's Guide
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Next Year's Game? Robert Cawthon Rumor Mill 537 30-10-2009 23:46
Next year's game? petek Rumor Mill 111 26-04-2008 02:59
Next Year's Robot? BandChick General Forum 10 29-03-2006 16:28
New Ideas for next year's competition XCJP General Forum 34 10-05-2005 10:07
Great Ideas For Next Year's Game MikeT Chit-Chat 0 15-05-2003 23:05


All times are GMT -5. The time now is 13:38.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi