parent
e5aad86370
commit
47c4882ff3
@ -1,15 +0,0 @@
|
||||
@inherits LayoutComponentBase
|
||||
|
||||
|
||||
<header><h1>Welcome to admin</h1></header>
|
||||
|
||||
<nav>
|
||||
<a href="/admin">home</a>
|
||||
<a href="/admin/users">users</a>
|
||||
</nav>
|
||||
|
||||
<div class="container">
|
||||
<main role="main" class="pb-3">
|
||||
@Body
|
||||
</main>
|
||||
</div>
|
@ -1,16 +0,0 @@
|
||||
<div class="alert alert-secondary mt-4">
|
||||
<span class="oi oi-pencil me-2" aria-hidden="true"></span>
|
||||
<strong>@Title</strong>
|
||||
|
||||
<span class="text-nowrap">
|
||||
Please take our
|
||||
<a target="_blank" class="font-weight-bold link-dark" href="https://go.microsoft.com/fwlink/?linkid=2149017">brief survey</a>
|
||||
</span>
|
||||
and tell us what you think.
|
||||
</div>
|
||||
|
||||
@code {
|
||||
// Demonstrates how a parent component can supply parameters
|
||||
[Parameter]
|
||||
public string? Title { get; set; }
|
||||
}
|
@ -1,28 +0,0 @@
|
||||
@typeparam TItem
|
||||
@using System.Diagnostics.CodeAnalysis
|
||||
|
||||
<table class="table">
|
||||
<thead>
|
||||
<tr>@TableHeader</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
@foreach (var item in Items)
|
||||
{
|
||||
if (RowTemplate is not null)
|
||||
{
|
||||
<tr>@RowTemplate(item)</tr>
|
||||
}
|
||||
}
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@code {
|
||||
[Parameter]
|
||||
public RenderFragment? TableHeader { get; set; }
|
||||
|
||||
[Parameter]
|
||||
public RenderFragment<TItem>? RowTemplate { get; set; }
|
||||
|
||||
[Parameter, AllowNull]
|
||||
public IReadOnlyList<TItem> Items { get; set; }
|
||||
}
|
@ -1,36 +0,0 @@
|
||||
TP2
|
||||
1
|
||||
A
|
||||
Le problème reader/writer est différent.
|
||||
Dans notre cas, on veut que des clients et des patissiers accèdent à une ressource partagée ; l'une en "lecture", l'autre en "écriture"
|
||||
Mais on veut aussi empêcher un client de prendre une patisserie s'il n'yen a aucune de prete, par exemple.
|
||||
Ca ressemble beaucoup plus à un problème producer/consumer.
|
||||
|
||||
B
|
||||
La boutique peut jouer le role de moniteur, comme elle gère les inputs outputs et connait le stock
|
||||
Elle définit un buffer de taille n, puis
|
||||
put() {
|
||||
if(getstock() == n) {
|
||||
notFull.await(); // ne pas ajouter si plein
|
||||
}
|
||||
/*
|
||||
do the putting ...
|
||||
*/
|
||||
// stock++ if necessary
|
||||
notEmpty.signal(); // annoncer que non vide
|
||||
}
|
||||
Symmétriquement,
|
||||
get() {
|
||||
if(getstock() == 0) {
|
||||
notEmpty.await(); // ne pas prendre si vide
|
||||
}
|
||||
/*
|
||||
do the getting ...
|
||||
*/
|
||||
// stock-- if necessary
|
||||
notFull.signal(); // annoncer que non plein
|
||||
}
|
||||
|
||||
Avec un arrayList, on pourra / devra implémenter un buffer circulaire, càd tracer la tete et la queue en indexes variables qu'on incrémente, modulo, tout le bazar
|
||||
|
||||
Depuis le main, on start() les Customers et PastryChefs qui héritent de Runnable
|
Loading…
Reference in new issue