lensowiki:Sandbox - Revision history

Lensovet: Replaced content with "weeeeeeeeee"

2011-06-15T09:06:46Z

Replaced content with "weeeeeeeeee"

Lensovet at 08:50, 15 June 2011

2011-06-15T08:50:42Z

0:0:0:0:0:0:0:1: clean, test confirmedit

2010-03-10T10:29:14Z

clean, test confirmedit

169.229.32.138: lisa's review

2009-05-11T20:53:07Z

lisa's review

169.229.156.15 at 23:53, 21 April 2009

2009-04-21T23:53:41Z

Lensovet at 17:20, 6 April 2009

2009-04-06T17:20:08Z

Lensovet at 04:33, 27 March 2009

2009-03-27T04:33:38Z

169.229.32.138: research links

2009-01-28T22:37:00Z

research links

Wadmin: clean

2008-09-24T22:55:10Z

clean

Wadmin at 22:50, 24 September 2008

2008-09-24T22:50:32Z

← Older revision		Revision as of 09:06, 15 June 2011
Line 1:		Line 1:
−	~~=Data analysis protocol (draft)=~~	+	weeeeeeeeee
−	~~;Current academic work describes 3 "selection" metrics and 2 "contract compliance" metrics.~~
−
−	;Current tool implementation contains 6 implemented metrics. An additional metric will be implemented in the near future. Based upon data availability, two of the metrics can be adjusted to account for unique sensors.
−
−	~~==Obtaining academic metrics using the tool==~~
−	~~Let us first describe how the metrics described in the academic work can be obtained using the tool.~~
−
−	~~===Selection metrics===~~
−	~~====Total number of datapoints (''T'')====~~
−	This metric represents the total number of datapoints provided by the feed in the time interval that has been selected. At the moment, this metric is not directly available but implementing it will be trivial. The total number of datapoints will be shown above the metric selection and will be updated whenever a new date range, feed, or network is chosen.
−
−	~~====Number of cells with data (''C'')====~~
−	This metric represents the total of number of mile-hour blocks which have more than ''k'' datapoints in them. This metric is not currently implemented directly. However, adding a display of it to the current space-time coverage chart will be trivial. Below the chart, a text field will allow the user to set the value of ''k'', after which the percentage of mile-hour blocks containing ≥''k'' datapoints will be calculated and displayed.
−
−	~~====Weighted number of cells with data (''W'')====~~
−	This is similar to ''C'' above but uses a weighted average instead of a binary delta function. Implementation difficulty is in effect the same as before, though the exact weighting function needs to be determined first.
−
−	~~===Contract compliance metrics===~~
−	~~====Spatial coverage (''s'')====~~
−	This metric represents the total number of datapoints in a given mile block summer over all hour blocks in the chosen time period. In effect, this is the tool's current space-time metric summed over time.
−
−	Obtaining the data itself will be trivial. However, it seems to me that the best way to visualize this information would be to display it on a map. This will take a bit more time but could be conceivably complete by the end of the week (assuming our systems cooperate…).
−
−	~~====Temporal coverage (''t'')====~~
−	This metric represents the total number of datapoints in the feed at a particular time block (i.e. hour). This metric is currently fully implemented with the tool's ''Time coverage'' metric. The user would pick the feed of interest, select the desired time interval, and then click on the '''Time coverage''' radio button. A graph of the temporal coverage is then presented. The user can hover over the graph to view individual metric values.
−
−	~~==Description of tool metrics==~~
−	The current version of the tool provides a number of graphs beyond those currently described in the academic context which would also be useful for evaluating the data. They are described in detail below.
−
−	~~===Speed===~~
−	This graph shows the average speed value in the given mile-hour block in miles per hour. This allows the user to sanity-check the data provided by the vendor to make sure that the speed values the vendor has provided are reasonable. For example, if we see that the average speed on an urban freeway during the morning rush hour is 80 mph, we can suspect that there is a problem with the data and can potentially further investigate where the data error lies.
−
−	~~===Map-matching error===~~
−	The map-matching error represents the distance from the original lat-long position of the raw data point to the nearest roadway segment in the network. The data used in this metric is only the subset of data located within a reasonable number of miles of the network's bounding box. The blue line represents the percentage of points which were successfully map-matched to a roadway segment which is ≤ 30 meters away from the raw data point. The green line shows the average distance (in meters) to the nearest roadway of the successfully-map-matched datapoints; shaded area represents one-half a standard deviation on either side of the average.
−
−	This metric can be useful in evaluating the positioning error of the devices used by the vendor to report speeds. If a high percentage of datapoints can't be mapmatched, it is possible that the vendor is supplying data that is not for the roadway in question or the positioning sensors used are of low quality.
−
−	~~===Transmission delay===~~
−	This chart displays the time difference between when the data point is recorded and when the data point has been received by the vendor (in seconds). A large transmission delay can be indicative of high network latencies between the sensor and the vendor servers, the vendor servers and the CCIT servers, or a bottleneck/delay on the CCIT servers themselves. In the case of the first two causes, high transmission delay makes the vendor largely unsuitable for real-time traffic management and monitoring purposes.
−
−	~~===Space-time coverage===~~
−	This chart shows the total number of datapoints recorded for the given mile-hour block. It is similar to the academic ''C'' metric but continues to distinguish between mile-hour blocks with different counts instead of using a single threshold. This metric makes it possible to evaluate the consistency of data volumes of the vendor throughout the day, while also making the next metric possible.
−
−	~~===Penetration rate===~~
−	This chart shows the estimated penetration rate of the vendor's data; that is, what percentage of the total occupancy of the freeway is made up of devices which supply data to the vendor. The methodology is as follows: first, all the valid PeMS stations along the route are retrieved. Each station's flows (which are reported at 30-second intervals) are summed across all of the lanes; these flows are then summed at hourly intervals. Then, the PeMS stations are bucketed into one-mile segments. The data from all the PeMS stations in a mile-hour block (which has already been summed for that hour) is then averaged to get the total occupancy in the mile-hour block. The number of unique devices in the data feed in the same mile-hour block is then divided by this total occupancy to get the penetration rate percentage.
−
−	~~'''Note''': concerns have been raised by Anthony about labeling this as "penetration rate". Work continues on providing a better theoretical basis for this metric.~~
−
−	~~===Time coverage===~~
−	~~This has already been described in the Temporal coverage (''t'') academic metric above.~~
−
−	~~===Unique device toggle===~~
−	For the ''space-time coverage'' chart described earlier, the '''Include only single point per device''' checkbox excludes duplicate points from the same sensor in each mile-hour box. That is, for any mile-hour block, only the first datapoint from a particular device is counted and included in the data that's then presented in graphical form.
−
−	Note that this feature is data-dependent, since it requires the presence of a unique device/sensor identifier for each datapoint. The RFP, as published, makes such a field ''optional'', rather than ''mandatory''.
−
−	~~===Future metric: sampling rate===~~
−	This metric displays the average time period between consecutive samples in the raw feed. The way in which this data will be displayed is currently undefined. It seems reasonable to extend the ''unique device toggle'' to this metric.
−
−	~~===Future functionality: feed overlays===~~
−	The tool should have the ability to overlay data for multiple feeds/vendors for the ''map-matching error'', ''transmission delay'', and ''time coverage'' metrics. A way to directly compare the amount of ''space-time coverage'' and ''penetration'' is also needed. One option is generate area charts for each of the mile-hour blocks (resulting in the same grid as with the absolute value chart), showing the proportion of total data from each vendor. Another option would be to provide the same chart as before (for individual feeds) with the absolute color replaced by a relative one, where the color value would represent the percentage of all data provided by this particular vendor (the ''unique device toggle'' would still function as before).

← Older revision		Revision as of 08:50, 15 June 2011
Line 1:		Line 1:
−	~~This can be used for testing out wiki markup. Enjoy~~.	+	=Data analysis protocol (draft)=
		+	;Current academic work describes 3 "selection" metrics and 2 "contract compliance" metrics.

−	~~http~~://~~google~~.~~com~~	+	;Current tool implementation contains 6 implemented metrics. An additional metric will be implemented in the near future. Based upon data availability, two of the metrics can be adjusted to account for unique sensors.
		+
		+	==Obtaining academic metrics using the tool==
		+	Let us first describe how the metrics described in the academic work can be obtained using the tool.
		+
		+	===Selection metrics===
		+	====Total number of datapoints (''T'')====
		+	This metric represents the total number of datapoints provided by the feed in the time interval that has been selected. At the moment, this metric is not directly available but implementing it will be trivial. The total number of datapoints will be shown above the metric selection and will be updated whenever a new date range, feed, or network is chosen.
		+
		+	====Number of cells with data (''C'')====
		+	This metric represents the total of number of mile-hour blocks which have more than ''k'' datapoints in them. This metric is not currently implemented directly. However, adding a display of it to the current space-time coverage chart will be trivial. Below the chart, a text field will allow the user to set the value of ''k'', after which the percentage of mile-hour blocks containing ≥''k'' datapoints will be calculated and displayed.
		+
		+	====Weighted number of cells with data (''W'')====
		+	This is similar to ''C'' above but uses a weighted average instead of a binary delta function. Implementation difficulty is in effect the same as before, though the exact weighting function needs to be determined first.
		+
		+	===Contract compliance metrics===
		+	====Spatial coverage (''s'')====
		+	This metric represents the total number of datapoints in a given mile block summer over all hour blocks in the chosen time period. In effect, this is the tool's current space-time metric summed over time.
		+
		+	Obtaining the data itself will be trivial. However, it seems to me that the best way to visualize this information would be to display it on a map. This will take a bit more time but could be conceivably complete by the end of the week (assuming our systems cooperate…).
		+
		+	====Temporal coverage (''t'')====
		+	This metric represents the total number of datapoints in the feed at a particular time block (i.e. hour). This metric is currently fully implemented with the tool's ''Time coverage'' metric. The user would pick the feed of interest, select the desired time interval, and then click on the '''Time coverage''' radio button. A graph of the temporal coverage is then presented. The user can hover over the graph to view individual metric values.
		+
		+	==Description of tool metrics==
		+	The current version of the tool provides a number of graphs beyond those currently described in the academic context which would also be useful for evaluating the data. They are described in detail below.
		+
		+	===Speed===
		+	This graph shows the average speed value in the given mile-hour block in miles per hour. This allows the user to sanity-check the data provided by the vendor to make sure that the speed values the vendor has provided are reasonable. For example, if we see that the average speed on an urban freeway during the morning rush hour is 80 mph, we can suspect that there is a problem with the data and can potentially further investigate where the data error lies.
		+
		+	===Map-matching error===
		+	The map-matching error represents the distance from the original lat-long position of the raw data point to the nearest roadway segment in the network. The data used in this metric is only the subset of data located within a reasonable number of miles of the network's bounding box. The blue line represents the percentage of points which were successfully map-matched to a roadway segment which is ≤ 30 meters away from the raw data point. The green line shows the average distance (in meters) to the nearest roadway of the successfully-map-matched datapoints; shaded area represents one-half a standard deviation on either side of the average.
		+
		+	This metric can be useful in evaluating the positioning error of the devices used by the vendor to report speeds. If a high percentage of datapoints can't be mapmatched, it is possible that the vendor is supplying data that is not for the roadway in question or the positioning sensors used are of low quality.
		+
		+	===Transmission delay===
		+	This chart displays the time difference between when the data point is recorded and when the data point has been received by the vendor (in seconds). A large transmission delay can be indicative of high network latencies between the sensor and the vendor servers, the vendor servers and the CCIT servers, or a bottleneck/delay on the CCIT servers themselves. In the case of the first two causes, high transmission delay makes the vendor largely unsuitable for real-time traffic management and monitoring purposes.
		+
		+	===Space-time coverage===
		+	This chart shows the total number of datapoints recorded for the given mile-hour block. It is similar to the academic ''C'' metric but continues to distinguish between mile-hour blocks with different counts instead of using a single threshold. This metric makes it possible to evaluate the consistency of data volumes of the vendor throughout the day, while also making the next metric possible.
		+
		+	===Penetration rate===
		+	This chart shows the estimated penetration rate of the vendor's data; that is, what percentage of the total occupancy of the freeway is made up of devices which supply data to the vendor. The methodology is as follows: first, all the valid PeMS stations along the route are retrieved. Each station's flows (which are reported at 30-second intervals) are summed across all of the lanes; these flows are then summed at hourly intervals. Then, the PeMS stations are bucketed into one-mile segments. The data from all the PeMS stations in a mile-hour block (which has already been summed for that hour) is then averaged to get the total occupancy in the mile-hour block. The number of unique devices in the data feed in the same mile-hour block is then divided by this total occupancy to get the penetration rate percentage.
		+
		+	'''Note''': concerns have been raised by Anthony about labeling this as "penetration rate". Work continues on providing a better theoretical basis for this metric.
		+
		+	===Time coverage===
		+	This has already been described in the Temporal coverage (''t'') academic metric above.
		+
		+	===Unique device toggle===
		+	For the ''space-time coverage'' chart described earlier, the '''Include only single point per device''' checkbox excludes duplicate points from the same sensor in each mile-hour box. That is, for any mile-hour block, only the first datapoint from a particular device is counted and included in the data that's then presented in graphical form.
		+
		+	Note that this feature is data-dependent, since it requires the presence of a unique device/sensor identifier for each datapoint. The RFP, as published, makes such a field ''optional'', rather than ''mandatory''.
		+
		+	===Future metric: sampling rate===
		+	This metric displays the average time period between consecutive samples in the raw feed. The way in which this data will be displayed is currently undefined. It seems reasonable to extend the ''unique device toggle'' to this metric.
		+
		+	===Future functionality: feed overlays===
		+	The tool should have the ability to overlay data for multiple feeds/vendors for the ''map-matching error'', ''transmission delay'', and ''time coverage'' metrics. A way to directly compare the amount of ''space-time coverage'' and ''penetration'' is also needed. One option is generate area charts for each of the mile-hour blocks (resulting in the same grid as with the absolute value chart), showing the proportion of total data from each vendor. Another option would be to provide the same chart as before (for individual feeds) with the absolute color replaced by a relative one, where the color value would represent the percentage of all data provided by this particular vendor (the ''unique device toggle'' would still function as before).

← Older revision		Revision as of 10:29, 10 March 2010
Line 1:		Line 1:
	This can be used for testing out wiki markup. Enjoy.		This can be used for testing out wiki markup. Enjoy.

−	~~Lisa,~~	+	http://google.com
−	~~Overall I think this is a great project and you know what you're doing. As for some general thoughts on improving the project proposal in general:~~
−	-The idea to have this influence consumer behavior is great; however, I think you need to expand on it further for us to better understand what exactly you're doing with it and how you aim to accomplish it. I don't think you should throw it out of the project, but rather, elaborate more on how consumers have a choice in what they buy and how their choices can have an impact on the environment. Then, tie it back to how produce comprises a large portion of the things we buy and how consumer knowledge of the data that you accumulate can help consumers make informed decisions and thus bring about change in the agricultural industry. (I realize that you sort of do this at the end of the introduction. Perhaps it would be better to move this up into where you first introduce the consumer theme, earlier in the text).
−	-In general, I sometimes feel like you're losing focus with some of the data you bring up toward the beginning of the introduction. Try to make sure we don't forget what the main thrust of the project is about.
−	-Another thing I think could use some elaboration is why you're mainly looking at fuel used (with the exception of soil emissions). In fact, I'm wondering if that's really the right term to use. For example, water transport doesn't really use "fuel", unless you're using tanker trucks to move it, and the production of pesticides/fertilizers has some sort of energy input, which, again, is probably not fuel as we think of it. Of course, these activities still generate greenhouse gases. I just think it would be better to be clearer in terminology and only use the term "fuel" for transport of supplies/etc to the farm and the transport of the food from the farm to the consumer/supplier/etc.
−	~~Again, I think this is a great project, and with a bit of work on streamlining, organization, and clarification, this will be a great proposal :)~~
−
−	~~http://az.lib.ru/c/chehow_a_p/text_0120.shtml~~
−	~~http://briefly.ru/~~
−
−	~~==CITRIS links==~~
−	~~http://www.citris-uc.org/research/projects/adaptive_real_time_geoscience_and_environmental_data_analysis_modeling_and_visualization~~
−	~~http://www.citris-uc.org/research/projects/data_on_the_deep_web_queries_trawls_policies_and_countermeasures~~
−	~~http://www.citris-uc.org/research/projects/deterministic_and_probabilistic_hybrid_control_of_air_traffic_management~~
−	~~http://www.citris-uc.org/research/projects/a_prototype_natural_hazards_geographic_data_library~~
−	http://~~www~~.~~citris-uc.org/research/projects/enhanced_information_and_communications_first_responders~~
−	~~http://www.citris-uc.org/research/projects/new_thermostat_new_temperature_node_and_new_meter_cec~~

← Older revision		Revision as of 20:53, 11 May 2009
Line 1:		Line 1:
	This can be used for testing out wiki markup. Enjoy.		This can be used for testing out wiki markup. Enjoy.
		+
		+	Lisa,
		+	Overall I think this is a great project and you know what you're doing. As for some general thoughts on improving the project proposal in general:
		+	-The idea to have this influence consumer behavior is great; however, I think you need to expand on it further for us to better understand what exactly you're doing with it and how you aim to accomplish it. I don't think you should throw it out of the project, but rather, elaborate more on how consumers have a choice in what they buy and how their choices can have an impact on the environment. Then, tie it back to how produce comprises a large portion of the things we buy and how consumer knowledge of the data that you accumulate can help consumers make informed decisions and thus bring about change in the agricultural industry. (I realize that you sort of do this at the end of the introduction. Perhaps it would be better to move this up into where you first introduce the consumer theme, earlier in the text).
		+	-In general, I sometimes feel like you're losing focus with some of the data you bring up toward the beginning of the introduction. Try to make sure we don't forget what the main thrust of the project is about.
		+	-Another thing I think could use some elaboration is why you're mainly looking at fuel used (with the exception of soil emissions). In fact, I'm wondering if that's really the right term to use. For example, water transport doesn't really use "fuel", unless you're using tanker trucks to move it, and the production of pesticides/fertilizers has some sort of energy input, which, again, is probably not fuel as we think of it. Of course, these activities still generate greenhouse gases. I just think it would be better to be clearer in terminology and only use the term "fuel" for transport of supplies/etc to the farm and the transport of the food from the farm to the consumer/supplier/etc.
		+	Again, I think this is a great project, and with a bit of work on streamlining, organization, and clarification, this will be a great proposal :)

	http://az.lib.ru/c/chehow_a_p/text_0120.shtml		http://az.lib.ru/c/chehow_a_p/text_0120.shtml

← Older revision		Revision as of 23:53, 21 April 2009
Line 2:		Line 2:

	http://az.lib.ru/c/chehow_a_p/text_0120.shtml		http://az.lib.ru/c/chehow_a_p/text_0120.shtml
		+	http://briefly.ru/

	==CITRIS links==		==CITRIS links==

@@ Line 1: / Line 1: @@
 This can be used for testing out wiki markup. Enjoy.
-==Proofread==
-Dostoevsky's The Double, written after the publication of Nikolai Gogol’s The Overcoat, was heavily influenced by the latter work. Dostoevsky's use of characters and themes directly from Gogol's short story exemplifies this influence in a very overt manner, and closer examination shows that the language and narrative style are at times also very Gogolian. On the other hand, The Double has the very Dostoevskyan quality of constant agony and highly introspective, psychological deliberations on the part of the main character. There is also an interesting related historical note: Dostoevsky’s original version of the novella, published in 1846, was subject to significant criticism from both literary critics and contemporaries, in part due to the prolonged narrative and its many tangential stories and dialogues, attributes which can be seen as Gogolian. The version we read today is a reworking of that original work and was published in 1866; Dostoevsky’s revisions included the elimination of these peripheral elements in the story and an overall “streamlining” of the plotline. However, Dostoevsky linked the story more directly to another work of Gogol, Dead Souls, with the subtitle of «A Petersburg Poema» (Dostoevsky, Sobranie Soch. 445); thus the novella’s relationship to Gogol did not even end after its initial publication.
+http://az.lib.ru/c/chehow_a_p/text_0120.shtml
 ==CITRIS links==

← Older revision		Revision as of 22:37, 28 January 2009
Line 1:		Line 1:
	This can be used for testing out wiki markup. Enjoy.		This can be used for testing out wiki markup. Enjoy.
	----		----
		+	http://www.citris-uc.org/research/projects/adaptive_real_time_geoscience_and_environmental_data_analysis_modeling_and_visualization
		+	http://www.citris-uc.org/research/projects/data_on_the_deep_web_queries_trawls_policies_and_countermeasures
		+	http://www.citris-uc.org/research/projects/deterministic_and_probabilistic_hybrid_control_of_air_traffic_management
		+	http://www.citris-uc.org/research/projects/a_prototype_natural_hazards_geographic_data_library
		+	http://www.citris-uc.org/research/projects/enhanced_information_and_communications_first_responders
		+	http://www.citris-uc.org/research/projects/new_thermostat_new_temperature_node_and_new_meter_cec

← Older revision		Revision as of 22:55, 24 September 2008
Line 1:		Line 1:
	This can be used for testing out wiki markup. Enjoy.		This can be used for testing out wiki markup. Enjoy.
	----		----
−	~~==Questions 1 - Thread.Join()==~~
−	~~Implementation:adding some text on this line~~
−	~~KThread has a new state variable joinedOnMe, a ThreadQueue.~~
−
−	~~If (CurrentThread == self or joinedOnMe != null){~~
−	~~Return; // conditions for join not satisfied~~
−	~~} else if (status == Finished){~~
−	~~Return;~~
−	}
−	~~Else {~~
−	~~currentThread.sleep;~~
−	~~joinedOnMe = currentThread;~~
−	}
−
−	~~Finished(){~~
−	…
−	~~joinedOnMe.ready();~~
−	}
−
−	~~Testing:~~
−	ThreadA prints out a few statements, calls ThreadB.join(), then prints out a few more statements. ThreadB also prints out a series of statements. We want to check that ThreadB executes contiguously to completion before ThreadA resumes its execution.
−
−	~~==Question 2 - Condition2==~~
−	~~Implementation:~~
−	~~Condition2 has a new state variable waitQueue, a ThreadQueue of Threads transferPriority false.~~
−	In the sleep() method we add the calling (current) thread to the waitQueue of threads. After the thread releases its condition lock, we disable interrupts and it is put to sleep. When it wakes up, interrupts are re-enabled and the thread attempts to reacquire the condition lock.
−
−	~~In the wait() method, if the waitQueue is not empty we ;~~
−	~~Sleep(){~~
−	~~disableInterrupts~~
−	~~waitQueue.waitforaccess(currentThread) // WAITFORACCESS~~
−	~~conditionLock.release~~
−	~~currentThread.sleep~~
−	~~conditionLock.acquire~~
−	~~enableInterrupts~~
−	}
−	~~Wake(){~~
−	~~Disable interrupts~~
−	~~Nt = waitqueue .nextthread~~
−	~~If (nt is not null){~~
−	~~Ready nt~~
−	}
−	~~Re-enable interrupts~~
−
−	~~wakeAll~~
−	~~while (waitqueue.nextthread != null)~~
−	~~wake()~~
−
−	~~Testing: DO MOE~~
−
−	~~==Question 3 - WaitUntil()==~~
−	~~;Implementation~~
−	~~Alarm has a new sorted PriorityQueue waitingThreads to keep track of when waiting threads should be woken, sorted on their wake times from lowest to highest.~~
−	~~It also has a new inner class named waitingThread which contains a reference to the KThread and its associated wakeTime(long).~~
−
−	~~waitUntil(time){~~
−	~~WaitingThread wt = new WaitingThread (currentThread, currentTime + time);~~
−	~~waitingThreads.add (wt);~~
−	~~currentThread.sleep;~~
−	}
−
−	~~timerInterrupt(){~~
−	~~while (WaitingThreads.peek().time <= currentTime){~~
−	~~WaitingThreads.pop().wake();~~
−	}
−
−	~~Class WaitingThread (){~~
−	~~KThread currentThread;~~
−	~~Long time;~~
−	}
−
−	~~;Testing~~
−	~~For or while loop that prints out a series of statements. Check that statements for different threads are all printed contiguously according to their respective wake times.~~
−
−
−	~~==Question 4 - Communicator==~~
−	~~;Implementation~~
−	We recognize the invariant that there will always be an unequal amount of speakers and listeners, because speakers and listeners are almost immediately paired off and return. The S/L on the larger queue will acquire lock, perform their actions, wake opposing queue and immediately return (if they slept they would be put on the end of the queue). S/L on smaller queue will acquire lock, perform their actions, sleep, and once woken up again by opposing queue, return.
−
−
−	Special condition for 1 on 1. Use a Boolean flag which indicates a transfer is in progress. The 2nd S/L will set the flag to true, perform its actions and wake the 1st S/L; any intruding 3rd S/L will not attempt to acquire the lock as long as this flag is true—this 3rdSL will sleep in its respective queue. The 1st S/L will be woken up by the 2nd S/L, set the Boolean to false, and return.
−
−	~~;Testing~~
−	~~DO ME.~~
−
−	~~==Question 5 - Priority Scheduler==~~
−	~~PriorityQueue~~
−	~~----~~
−	NextThread get most important member off Priority and Time queue. LastThread variable is set when NextThread or acquire is called. Also triggers recalculation on popped off LastThread and popped off thread which becomes the LastThread.
−
−	~~PickNextThread inspect first thread without removing it and return ThreadState.~~
−
−	~~New Instance variable of effectivepriority~~
−	~~GetEffectivePriority returns cached effective priority of a thread capped @ maxpriority~~
−
−	~~SetPriority~~
−	~~Change actual priority of current thread~~
−	~~Change effective priority of lastthread by difference between current threads priority and new priority.~~
−
−	~~If set priority is called on a thread with effective priority must make sure effective priority is still present, ex: 5+5, set priority to 0, thread should still have 5.~~
−
−	~~Make sure to check for transfer priority—procedure is different: ex: always return regular priority if transferpriority== false~~
−
−
−	~~PriorityScheduler.waitforaccess(thread)~~
−
−
−	~~ThreadState.WaitForAccess(priorityQueue)~~
−	~~Put thread onto time&priority wait queue. Sorts all by priority , time.~~
−	~~Recalculates effective priority.~~
−
−	~~Acquire~~
−	~~recalculate LastThread effective priority.~~
−	~~Set CurrentThread = LastThread and recalculate priority.~~
−
−	~~Recalculation: iterate through structure and add up all priorities.~~
−
−
−	~~When thread calls threadstate.acquire you get donation of all threads on waitqueue~~
−	~~Three things that change your priority: when another thread is added to queue waiting on you, when you acquire, when you release~~
−	~~Use treeset to keep track of all threads sorted on time~~
−
−	~~Every thread has a cached effective priority integer~~
−	~~Set when acquire / next thread~~
−	~~Wait for thread doesn’t call calculate priority on itself, calls calculate priority on current thread~~
−	~~Waitforaccess add to something that keeps track of priority and time~~
−
−	~~TESTING: DO ME.~~
−
−	~~==Question 6 - Boat==~~
−	~~CHILD who thinks he’s the last person must sleep, but communicate to begin and say he’s done. In that case, pilot must go to sleep instead of immediately piloting back.~~
−	~~# of children seen == # of children gone~~
−
−	TESTING: set up some test cases i.e. 2 children 0 adults, 2 children 1 adult, 2 children 2 adults, 3 children 2 adults, 5 children 3 adults and work them out mathematically. then verify that threads execute the same solution.

@@ Line 2: / Line 2: @@
 ----
 ==Questions 1 - Thread.Join()==
-Implementation:
+Implementation:adding some text on this line
 KThread has a new state variable joinedOnMe, a ThreadQueue.