カスティーリャ・イ・レオン州レオン県のバビア、ラシアーナ、エル・ビエルソ、ラ・カブレーラの各地域、ガリシア州オウレンセ県のコマルカ・デ・バルデオーラスを通る。町としてはレオン県のビジャブリーノ、ポンフェラーダ、オ・バルコ・デ・バルデオーラス、ア・ルーア、キローガ、リバス・デ・シルを通る。リベイラ・サクラなどでシル川が形成する峡谷はこの地域のアイデンティティを形成し、流域には中世からの歴史を持つ、主にロマネスク様式で建築された数十の修道院がある。ミーニョ川との合流前にはオウレンセ県とルーゴ県の自然的境界を形成している。ミーニョ川水系の本流であるミーニョ川にはオウレンセ県のオス・ペアーレスで合流する。一般的に河川の本流と支流のヒエラルキーは流量や全長で決まるが、ドゥエロ川水系におけるエルサ川やピスエルガ川のように、シル川は本流であるはずのミーニョ川を水量で上回っている上に、全長でも約20km上回っている。「ミーニョ川は名声を持つ。一方でシル川は水量を与える」(El Miño lleva la fama y el Sil le da el agua)という格言がある。
市立船橋高校から順天堂大学を経て、2002年よりJFLの佐川急便東京SCに加入。長身かつプレーエリアの広い万能型FWとして初年度から出場機会を得たものの、翌年からはケガもあってレギュラーに定着できない時期を過ごした。そのなかで2004年の天皇杯では、3回戦のジュビロ磐田戦で2得点をあげ、一時逆転リードを奪う健闘の立役者となった。2006年は当初途中出場が中心であったが、チームの連携が深まったシーズン中盤以降に先発出場の機会を得ると5試合で6得点とブレイクを見せ、初めて全試合出場を果たすとともにシーズン10得点と成績を伸ばした。2007年、佐川東京SCが佐川急便大阪SCと合併して新たに発足した佐川急便SC（後のSAGAWA SHIGA FC）に加入。レギュラーの座を失ったもののスーパーサブとして勝負所で投入され、出場時間は少ないながら前年同様の10得点と結果を残した。翌2008年には先発出場が増え、チームの調子が上がらないなかこの年も10得点と奮闘。2009年以降はケガの影響で出場を減らした時期もあったが、競り合った試合での得点力を買われて、チームが活動停止となる2012年までSAGAWA SHIGAで活躍を続けた。2013年より、長くチームメイトである山根伸泉とともに地元千葉県のVONDS市原に加入し、プレーを続けている。
ヤーレーン(Yaren)は、トルコの楽器。三連サズともいう。涙型胴ギターが三つつながった形をしており、それぞれ大きさや音程の高さが違う。 ヤーレーンの元の楽器のサズは、本来はいくつかの種類のものを持ち替えて使うのだが、これは三種類をくっつけてしまっている。
スレッドにおいてロックはメモリ上の値を用いて実装される．複数のスレッドが同時に値を取得・変更できない必要があるが，これを効率的に実装するため，ロックは一般にハードウェアによるサポートを必要とする。通常、1つ以上のアトミック命令を使用する（「テスト・アンド・セット」、「フェッチ・アンド・アッド」、「コンペア・アンド・スワップ」など）。これらの命令は、プロセスがロックが獲得されていない（フリーである）ことをチェックするとともに、不可分な（アトミックな）処理としてロックを獲得できる。プロセッサが1つであれば、割り込みを禁止して命令列を実行することで同等の効果が得られる。しかし、マルチプロセッサではこれでは不十分である。マルチプロセッサ環境でロックをサポートすることはハードウェアとソフトウェアの複雑なサポートを要し、同期の主要な課題でもある。アトミックな操作が必要とされる理由は、並列処理では複数のタスクが同じロジックを同時に実行している可能性があるからである。例えば、以下のC言語のコードを考えてみよう。if (lock == 0) {    /* ロックがフリーなのでセットする */    lock = myPID; }複数のタスクが並行して動作可能なら、上記のコードはロックを獲得できるとは言えない。どちらのタスクもロックがフリーであると判断し、どちらもロックに自身のIDをセットして獲得しようとするが、他のタスクも同時にロックを獲得しようとしていることを知らない。アトミックなロック操作ができないときは、デッカーのアルゴリズムやピーターソンのアルゴリズムで代替することもできる。ロックの不注意な使用によりデッドロックが生じることがある。これはプロセスがあるロックを獲得した状態で別のロックを獲得しようとしたときに発生する。もし2番目のロックが別のプロセスに獲得されていれば、最初のプロセスはブロックされる。2番目のプロセスが最初のプロセスが獲得済みのロックを獲得しようとすると、システムは「デッドロック」状態となり、どちらのプロセスもブロックされたままとなる。これを防ぐための（あるいは回復するための）様々な戦略が設計時や実行時に採用されている。例えば、各ロックが保護するデータの種類によってロックに優先順位を設定し、順位通りでないとロックを獲得できないようにするなどの対処がある（ただし、同じ種類のデータを2つロックしなければならないときなどはデッドロックに注意しなければならない）。言語によっては構文規則上ロックをサポートしていることもある。C#での例を以下に示す。class Account {     // 口座のモニター  long val = 0;  object thisLock = new object();  public void Deposit(const long x) {    lock (thisLock) {   // 一度に1スレッドしか、この文を実行できない      val += x;    }  }   public void Withdraw(const long x) {    lock (thisLock) {      val -= x;    }  }}lock (this) は、そのインスタンスにパブリックにアクセスできる場合、問題を生じる。Javaと同様、C#もメソッド全体を同期させることができ、MethodImplOptions.Synchronized という属性を使用する。 [MethodImpl(MethodImplOptions.Synchronized)]  public void SomeMethod () {// do stuff  }